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FOREWORD 


The  Innovative  Tools  and  Techniques  for  Brigade  and  Below  Staff  Training  (ITTBBST) 
program  is  part  of  the  U.S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences  (ARI) 
ongoing  research  to  establish  innovative  methods  for  training  combined  arms  forces.  The 
ITTBBST  program  has  three  major  parts:  Battlefield  Functions  (BFs),  Battle  Staff  Training 
System  (BSTS),  and  the  Staff  Group  Trainer  (SGT).  The  BFs  are  defined  as  processes  or 
activities  occurring  over  time  that  must  be  performed  to  accomplish  a  mission  or  supporting 
critical  tasks.  A  BF  provides  task  integration,  combined  arms  interaction,  and  inter-Battlefield 
Operating  System  (BOS)  linkages.  The  BSTS  is  a  research  program  using  paper  and  multimedia 
products  to  train  brigade  and  battalion  staff  officers  in  basic  skills  necessary  to  perform  their  jobs. 
The  SGT  is  a  research  and  development  (R&D)  effort  designed  to  train  small  staff  groups  in  basic 
information  management  skills. 

The  current  turbulence,  staff  experience  levels  and  lack  of  effective  training  opportunities 
in  battalion  and  brigade  staffs  combine  to  create  a  training  challenge  for  commanders.  The  SGT 
R&D  effort  is  designed  to  provide  the  commander  a  tool  he  can  use  to  meet  this  challenge.  The 
purpose  of  the  SGT  R&D  effort  is  to  conduct  research  on  training  basic  information  management 
skills  needed  during  mission  execution  by  a  new  or  inexperienced  staff.  The  SGT  assumes  that 
individual  staff  members  are  knowledgeable  in  their  individual  areas.  The  SGT  R&  D  program  is 
designed  to  bridge  the  training  gap  between  individual  skills  and  integrated  staff  skills,  preparing  a 
staff  for  mission  exercises  in  constructive  simulations  or  field  exercises. 

The  training  objectives  of  the  SGT  are  ten  staff  processes  involved  in  the  staff  decision 
making  cycle  of  see,  assess,  decide  and  act.  The  SGT  R&D  effort  uses  the  structured  training 
method.  This  involves  developing  detailed  training  support  packages  (TSPs)  containing  events  (in 
this  case,  message  traffic)  causing  the  staff  processes  to  be  performed.  Information  is  collected  to 
provide  feedback  to  the  training  audience  concerning  how  well  these  processes  were  performed,. 
This  information  is  presented  to  the  training  audience  in  After  Action  Reviews  (AARs) .  Training 
progresses  in  difficulty  using  a  crawl,  walk,  run  sequence. 

The  SGT  R&D  effort  consists  of  two  TSPs,  one  for  brigade  and  one  for  battalion.  Each 
of  these  TSPs  contain  tables  training  staff  processes  associated  with  staff  section,  command  post 
and  command  and  control  levels.  The  TSPs  use  computers  to  emulate  communications  systems  in 
delivering  a  stream  of  scripted  messages  from  higher,  lower  and  adjacent  headquarters. 
Information  on  performance  of  staff  processes  is  recorded  by  both  computers  and  a  minimum 
number  of  observer  controllers  using  checklists  describing  staff  actions  expected  based  on  the 
message  stream  (or  cues)  received  by  the  staff.  The  turnkey  features,  train  the  trainer  materials, 
and  TSPs  are  aimed  at  making  this  an  easy  to  use  program  that  requires  minimum  preparation 
time  on  the  part  of  the  commander  and  his  staff  to  train  staff  processes  in  the  execution  phase  of  a 
unit  mission 

This  report  documents  the  methodology  and  lessons  learned  in  the  SGT  project.  The 
report  describes  the  rationale  on  which  the  R&D  program  is  based,  overall  design  of  SGT, 
software,  exercise  and  TSP  development,  the  formative  evaluation,  lessons  learned  and  overall 
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conclusions.  The  report  provides  researchers  and  decision  makers  an  overall  understanding  of  the 
SGT  R&D  effort. 

The  SGT  has  been  used  by  the  149th  Armored  Brigade  of  the  Kentucky  National  Guard, 
and  is  slated  for  use  by  a  brigade  of  the  Texas  National  Guard.  Upon  completion  of  the  R&D 
effort,  it  will  be  delivered  to  the  Directorate  of  Training  and  Doctrinal  Development  (DTDD)  of 
the  U.  S.  Army  Armor  School  and  Center  at  Fort  Knox,  KY.  The  DTDD  will  make  decisions 
concerning  future  refinement,  use,  and  prospective  fielding  of  the  SGT  R&D  effort  and  its 
products. 


ZITAM.  SIMUTIS 
Technical  Director 
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STAFF  GROUP  TRAINER:  DEVELOPMENT  OF  A  COMPUTER-DRIVEN, 
STRUCTURED,  STAFF  TRAINING  ENVIRONMENT 


EXECUTIVE  SUMMARY  _ 

Research  Requirement: 

Maneuver  staffs  needed  a  tool  to  bridge  the  training  gap  between  the  skills  achieved 
through  individual  training  and  the  collective  skills  required  of  an  entire  battalion  or  brigade  staff. 
The  contemporary  battlefield  inundates  a  staff  with  information.  Battalion  and  brigade  staffs  must 
possess  strong  information  management  skills  if  they  are  to  perform  their  mission  successfully. 
Staff  members  must  attend  to  more  information  while  responding  with  greater  detail  and  speed 
than  ever  before. 

At  the  same  time,  factors  such  as  downsizing,  decreasing  defense  budgets,  and  the 
emergence  of  advanced  battlefield  weaponry  are  impacting  training  requirements.  These  factors 
create  a  need  for  less  resource  intensive  training.  An  outcome  of  this  evolution  is  an  Army  need 
to  develop  innovative  programs  aimed  at  training  soldiers  to  function  effectively  as  battalion  and 
brigade  staffs  on  the  modem  battlefield. 

The  goal  of  this  research  and  development  effort  was  to  develop  computer-driven, 
structured  staff  training  focused  on  the  military  decision-making  process.  The  program  was  to 
develop  innovative  tools  and  techniques  to  bridge  the  training  gap  between  individual  skills 
training  and  the  collective  level  of  interaction  and  tactical  decision-making  provided  by  the 
constructive  simulation  staff  training  environment. 

Procedure:  .  . . . - - 

The  development  team  analyzed  the  gap  in  staff  training  between  individual  training  and 
collective  training  on  the  Janus  or  Brigade/Battalion  Battle  Simulation  (BBS)  simulations  and 
designed  two  training  programs— battalion  and  brigade— to  bridge  that  gap.  Each  training  program 
was  composed  of  progressive  tables  advancing  from  individual  staff  section  to  command  post 
(CP)  and  then  to  command  and  control  (C2)  tables.  A  C2  table  involved  multiple  CPs.  Each  table 
was  divided  into  modules— section  specific  modules  for  the  staff  section  table,  CP  modules  (e.g., 
tactical,  main,  and  rear  CP  modules  for  the  brigade  program)  for  the  CP  table,  and  mission 
(movement  to  contact,  defense  [battalion  defense  in  sector  and  brigade  area  defense],  and 
deliberate  attack)  modules  for  the  C2  table.  Within  each  module,  the  team  developed  2-4 
exercises  with  support  materials,  organized  into  a  training  support  package  (TSP)  for  each 
program-battalion  and  brigade.  After  internal  testing  of  the  exercises,  the  exercises  and  training 
system  were  pilot  tested  with  soldiers.  After  making  suggested  modifications  in  the  exercises  and 
TSPs,  the  training  programs  were  tested  with  surrogate  staffs  and  a  training  team.  Suggestions 
from  these  tests  were  incorporated  into  the  final  TSPs. 

At  the  start  of  the  project,  the  Staff  Group  Trainer  hardware  suite  consisted  of  six  Sun 
SPARC  workstations  linked  by  a  local  area  network  (LAN).  Two  workstations  were  added  later 
in  the  project.  Each  workstation  consisted  of  two  19-inch  color  monitors,  a  keyboard,  a 
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processor,  and  a  mouse.  A  military  tactical  map  was  displayed  on  the  left-hand  monitor.  A 
message  display  was  on  the  right  monitor.  One  workstation  was  used  to  control  the  exercise. 

This  workstation  sent  pre-scripted  messages  to  the  other  workstations. 

Findings: 

The  concept  of  using  a  computer-driven,  structured  training  environment  to  train  new  or 
inexperienced  staffs  was  found  to  be  viable.  The  computer  system  delivered  scripted  message  lists 
that  reduced  training  overhead.  Approaches  for  unit  training  preparation  and  methods  for 
structuring  the  after  action  review  (AAR)  were  observed  to  benefit  the  trainers  and  staff. 

The  training  system  needs  further  development  for  staff  use.  Staff  personnel  cannot  afford 
to  invest  time  in  learning  how  to  use  a  training  system  that  differs  from  their  operational  systems. 
The  training  program  must  either  emulate  or  run  on  actual  equipment  or  require  minimal  training 
time. 


The  multimedia  general  situation  previews  were  very  effective  in  preparing  the  staff  for  the 
exercise.  A  similar  presentation  in  the  form  of  specific  section  previews  should  be  developed  for 
each  staff  section.  Staffs  must  be  brought  into  both  the  general  situation  and  the  specific  situation 
for  their  section.  The  multimedia  presentation  has  the  potential  of  rapidly  meeting  this  challenge. 
A  staff  process  model  (graphic)  proved  to  be  an  effective  means  of  focusing  the  staff  on  task 
performance.  This  graphic  presentation  of  staff  actions  was  effective  in  AARs.  The  multimedia- 
assisted,  end-of-module  AAR  aided  the  commander  and  training  team  in  presenting  a  focused 
AAR. 

Utilization  of  Findings: 

The  Staff  Group  Trainer  developed  two  staff  training  support  packages— battalion  and 
brigade.  More  work  is  required  to  refine  these  programs  and  the  delivery  system  into  a  useable 
tool  for  the  commander  in  the  field.  Ultimately,  battalion  and  brigade  staffs  will  be  able  to  use 
these  training  programs  to  develop  staff  proficiency  and  enhance  combat  readiness.  Follow-on 
research  can  build  on  the  foundation  established  by  this  project  to  improve  both  the  delivery 
system  and  the  training  programs.  Future  sponsors,  designers,  developers,  and  trainers  can 
benefit  by  applying  the  lessons  learned. 
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STAFF  GROUP  TRAINER:  DEVELOPMENT  OF  A  COMPUTER-DRIVEN,  STRUCTURED 

STAFF  TRAINING  ENVIRONMENT 


INTRODUCTION 

The  Staff  Group  Trainer1  Project  was  a  research  and  development  program  to  develop 
computer-aided,  structured  staff  training  using  the  execution  phase  of  three  combat  missions: 
movement  to  contact,  defense,  and  deliberate  attack— to  focus  on  the  military  decision-making 
process.  The  Staff  Group  Trainer  Project  produced  two  separate  training  support  packages 
(TSP)--one  for  a  heavy  maneuver  battalion/task  force,  and  one  for  a  heavy  maneuver  brigade. 
Within  both  TSPs,  the  exercises  were  designed  to  be  progressively  more  difficult  (crawl,  walk, 
run).  Both  programs  contained  three  components— staff  section  exercises  (training  within  the 
section,  or  "intra-staff”),  Command  Post  (CP)  exercises  (training  within  the  whole  CP,  i.e., 
between  sections  or  "inter-staff"),  and  Command  and  Control  (C2)  exercises  (training  between 
CPs,  e.g.,  main  and  rear  CPs). 

Background 

Current  evolution  of  the  U.S.  Army  requires  innovation  in  manning,  training,  and 
equipping  the  force.  Factors  such  as  downsizing,  decreasing  defense  budgets,  and  the  emergence 
of  advanced  battlefield  weaponry  are  creating  new  training  requirements.  These  factors  clearly 
create  a  need  for  less  resource  intensive  training.  Not  only  must  a  soldier  of  the  21  st  century 
possess  new  skills;  he/she  faces  the  challenges  of  increased  staff  turnover  currently  facing  the 
Army.  Additionally,  data  collected  from  the  Combat  Training  Centers  have  identified  deficiencies 
in  training  staff  synchronization  (Thompson,  Pleban,  &  Valentine,  1994;  Department  of  the  Army, 
1996).  One  outcome  is  an  identified  Army  need  to  develop  innovative  programs  aimed  at  training 
soldiers  to  function  effectively  as  battalion  and  brigade  staffs  on  the  modem  battlefield.  The  Staff 
Group  Trainer  Project  addressed  this  need.  This  project  was  developed  under  the  Force  XXI 
Training  Program  (FXXITP),  a  program  to  carry  the  Army’s  training  capabilities  into  the  21st 
Century  (Department  of  the  Army,  1994). 

The  contemporary  battlefield  inundates  a  staff  with  information.  It  is  vital  that  battalion 
and  brigade  staffs  possess  strong  information  management  skills  if  they  are  to  successfully 
perform  their  mission.  Staff  members  must  attend  to  more  information  while  responding  with 
greater  detail  and  speed  than  ever  before.  This  challenges  staff  personnel  and  their  capacity  to 
process,  analyze,  coordinate  and  integrate  information,  and  make  recommendations. 

The  predecessor  Commander/Staff  Trainer  (C/ST)  was  developed  under  the  Simulation- 
based  Multiechelon  Training  Program  for  Armor  Units  (SIMUTA)  program.  It  consisted  of  a 
computer  networked  system  with  six  workstations  supporting  a  battalion  staff  exercise  aimed  at 
training  information  processing  for  principal  staff  officers  in  the  main  CP  and  combat  trains  CP 


1  Staff  Group  Trainer  was  originally  called  Commander/Staff  Trainer  (C/ST).  The  name  was  changed  in  summer 
1996. 
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processing  for  conventional  forces,  with  staff  officers  directing  disposition  of  incoming  messages 
and  creating  minimal  message  traffic  within  a  movement  to  contact  scenario.  Textual  feedback 
modules  linked  to  individual  performance  during  the  mission,  focusing  strictly  on  message 
handling  and  overlay  maintenance,  were  present  on  individual  workstations.  The  SIMUTA  C/ST 
Project  did  not  train  staff  interaction. 

The  SIMUTA  Program  was  part  of  the  Reserve  Component  Virtual  Training  Program 
(RCVTP).  The  RCVTP  was  established  at  Fort  Knox,  Kentucky  to  develop  innovative  structured 
training  for  the  total  armor  force  so  that  networked  simulation  technologies  could  be  folly 
exploited.  The  RCVTP  was  redesignated  the  Virtual  Training  Program  (VTP)  to  more  accurately 
reflect  a  total  force  program. 

The  U.S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences’  (ARI’s) 
statement  of  work  for  a  follow-on  to  the  SIMUTA  C/ST  Project  was  included  in  the  "Innovative 
Tools  and  Techniques  for  Brigade  and  Below  Staff  Training  (ITTBBST)"  Program.  This 
program  called  for  enhancements  to  the  SIMUTA  C/ST  software  and  exercises  and  specified 
adding  battalion-level  defense  in  sector  and  deliberate  attack  missions  and  retrofitting  the 
movement  to  contact  mission  developed  for  the  SIMUTA  C/ST  Project.  It  also  required 
development  of  brigade  exercises  for  the  area  defense,  deliberate  attack,  and  movement  to  contact 
missions.  Under  the  ITTBBST  Program,  the  Staff  Group  Trainer  Project  became  part  of  an 
integrated  training  strategy  including  the  Battle  Staff  Training  System  (BSTS)  based  on 
Battlefield  Functions  (BFs)2.  More  information  on  BFs,  particularly  those  related  to  command 
and  control  of  the  armored  brigade,  can  be  found  in  Ford,  Mullen  and  Keesling  (1997). 

The  BSTS  Project  developed  computer-assisted  instruction  on  individual  staff  skills  for 
commanders  and  staff  officers  in  armored  and  mechanized  infantry  battalions  and  brigades.  The 
BF  Project  analyzed  processes  or  activities  performed  to  accomplish  a  mission  or  support  critical 
tasks.  The  BFs  provided  developers  in  the  BSTS  and  Staff  Group  Trainer  Projects  with  detailed 
descriptions  of  C2  functions  emphasizing  linkages  and  dependencies  among  maneuver,  combat 
support,  and  combat  service  support  elements.  The  BFs  established  a  common  framework  for 
designing  and  implementing  performance  measurement  and  after  action  reviews  (AARs). 

The  Staff  Group  Trainer  Project's  training  exercises  were  designed  to  serve  as  the  "bridge" 
between  individual  staff  officer  skills  training  provided  by  the  BSTS  and  the  structured  unit 
training  provided  by  simulation-driven  exercises  developed  in  ARI’s  SIMUTA,  Simulation-based 
Mounted  Brigade  Training  (SEMBART)  and  Combined-arms  Operations  at  Brigade  Level, 
Realistically  Achieved  through  Simulation  (COBRAS)  Programs  (Figure  1).  At  a  macro  level,  the 
BFs  provided  a  task-based  strategy  for  staff  training  and  provided  objective  performance 
measures  for  the  Staff  Group  Trainer  Project.  Thus,  the  BFs  provided  the  structure  to  span  the 
training  gap  from  BSTS  to  Janus-driven  exercises  with  the  VTP  or  FXXITP. 


2  The  term  "Battlefield  Function  (BF)"  was  designated  by  the  U.S.  Army  Training  and  Doctrine  Command 
(TRADOC)  in  September  1996  to  replace  "Critical  Combat  Function  (CCF)." 
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In  the  ITTBBST  Program,  the  ideal  training  progression  begins  with  BSTS  training  to 
develop  the  individual's  understanding  of  his  staff  responsibilities.  Staff  members  then  participate 
in  a  series  of  Staff  Group  Trainer  exercises.  These  dynamic  small  group  training  experiences 
focus  on  staff  processes  needed  to  support  the  commander’s  battlefield  awareness,  recommend 
courses  of  action,  and  support  the  commander's  decisions.  The  structured  messages  sets  and 
short  situational  exercises  focus  the  staffs  on  intra-  and  inter-staff  processes.  Participation  in  Staff 
Group  Trainer  exercises  helps  prepare  staff  members  for  an  increased  level  of  interaction  and 
tactical  decision-making  provided  by  the  Janus  or  Brigade/Battalion  Battle  Simulation  (BBS) 
collective  training  environment. 


Figure  1.  Staff  Group  Trainer  Project  training  progression. 
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Review  Of  Preceding  Projects 

The  Staff  Group  Trainer  Project  had  its  roots  in  two  related  areas.  The  first  was  the  ARI 
Armored  Forces  Research  Unit  (AFRU)  research  on  future  battlefield  conditions.  The  second 
was  ARI  AFRU  research  on  structured,  simulation-based  training  for  mounted  forces. 

Starting  in  the  late  1980s,  the  ARI  AFRU  conducted  a  series  of  experiments  to  evaluate 
new  tools  and  equipment  (position  navigation  system,  command  and  control  display,  and 
commander's  independent  thermal  viewer),  which  the  Army  was  planning  to  bring  to  the  armored 
forces.  Much  of  this  research  effort  fell  under  the  Combat  Vehicle  Command  and  Control 
(CVCC)  Program.  It  began  by  evaluating  each  piece  of  equipment  at  crew  and  tank  platoon 
levels  (Du  Bois  &  Smith,  1989,  1991;  Quinkert,  1990).  From  crew  and  platoon  levels,  the 
research  progressed  to  evaluating  the  integrated  impacts  of  all  tools  and  equipment  at  company 
level  (Leibrecht,  Kerins,  Ainslie,  Sawyer,  Childs  &  Doherty,  1992)  and  then  at  battalion  level 
(O'Brien,  Wigginton,  Morey,  Leibrecht,  Ainslie,  &  Sawyer,  1992;  Leibrecht,  Meade,  Schmidt, 
Doherty,'  &  Lickteig,  1994;  Meade,  Lozicki,  Leibrecht,  Smith,  &  Myers,  1994;  Atwood,  Winsch, 
Sawyer,  Ford,  &  Quinkert,  1994).  A  limited  part  of  the  research  effort  at  battalion  level  focused 
on  the  role  of  the  battalion  tactical  operations  center  (TOC)  equipped  with  automated 
workstations  (O’Brien  et  al.  1992).  This  initial  research  with  automated  workstations  provided  the 
equipment  and  impetus  to  continue  investigating  an  approach  for  training  effective  and  efficient 
staff  processes. 

The  second  origin  of  the  Staff  Group  Trainer  Project  came  from  research  in  structured 
training  conducted  under  SIMUTA  starting  in  1993  (R.  G.  Hoffman  et  al.  1995).  The  intent  of 
SIMUTA  was  to  provide  compressed,  turnkey  training  to  units  in  a  simulation  environment 
focusing  on  the  mission  execution  phase.  Unit  collective  training  was  developed  for  tank, 
mechanized  infantry,  and  scout  platoons;  tank  companies  and  tank-heavy  company/teams,  tank 
battalions  and  tank-heavy  task  forces;  and  tank  or  tank-heavy  battalion/task  force  staffs.  Training 
materials  were  developed  and  packaged  as  a  library  of  structured  simulation-based  training 
exercises  which  a  unit  commander  could  use  to  meet  unit  training  needs.  These  exercises  came 
with  a  complete  TSP  including  a  multimedia  program  orientation  and  planning  materials  with 
complete  operation  orders  (OPORDs)  for  the  units;  and  job  aids,  exercise  checklists  and  feedback 
guidelines  for  observers  to  use  during  preparation,  execution,  and  AARs.  The  TSP  also  included 
guidelines  for  preparing  take  home  packages  (THPs)  for  units  after  they  complete  their  training. 
The  SIMUTA  program  (C.  H.  Campbell,  R.  C.  Campbell,  Sanders,  Flynn,  &  Myers,  1995;  R.  G. 
Hoffman  et  al.  1995)  provided  a  basis  for  the  orders,  TSPs,  THPs,  and  structured  simulation- 
based  training  development  methodology  of  several  follow-on  programs  including  the  Staff  Group 
Trainer  Project. 

The  C/ST  project  was  part  of  the  SIMUTA  program  and  used  CVCC  technology  as  a 
base.  The  CVCC  TOC  workstations  were  used  as  exercise  drivers  and  part-task  trainers  for 
primary  battalion  staff.  Simulation  Networking  (SIMNET)  acted  as  a  driver  for  the  CVCC 
soldier-in-the-loop  simulations  for  mission  rehearsals,  war  gaming,  execution,  and  AARs.  The 
C/ST  workstations  were  different  from  the  CVCC  TOC  workstations  in  their  purpose-training 
versus  research.  Since  the  ARI  AFRU  wanted  training  to  focus  on  information  processing,  the 
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ARI  research  team  developed  four  exercises  based  on  the  SIMUTA  movement  to  contact 
scenario.  The  SIMUTA  C/ST  hardware/software  package  established  the  baseline  from  which  the 
Staff  Group  Trainer  Project’s  hardware/software  package  evolved. 

Three  preceding  projects— SIMUTA,  SIMBART,  and  SIMUTA  -  Battalion  Exercise 
Expansion  (SIMUTA-B)-provided  baseline  OPORDs  and  the  framework  for  the  tactical 
structure  of  the  Staff  Group  Trainer  Project’s  scenarios.  They  also  provided  the  initial 
methodology  for  design  and  development  of  training  exercises  and  TSPs. 

Problem  Statement 

As  represented  in  Figure  1,  maneuver  staffs  needed  a  tool  to  bridge  the  training  gap 
between  the  skills  achieved  by  a  primary  staff  officer  who  had  participated  in  BSTS  training  and 
the  collective  skills  required  of  an  entire  battalion  or  brigade  staff  using  SIMUTA,  SIMBART  or 
COBRAS  training  exercises.  The  Staff  Group  Trainer  Project  development  team’s  front-end 
analysis  indicated  this  gap  should  be  spanned  by  a  stepped  training  package.  This  translated  into 
staff  cell  training  (small  groups  of  individuals  from  a  staff  section  operating  within  a  CP),  CP 
training,  and  training  of  the  collective  staff  operating  in  multiple  CPs.  The  development  team 
found  a  need  for  training  emphasis  on  the  staffs  synthesis  of  information  and  the  communication 
of  that  information  to  the  commander  so  that  he  could  use  it  in  his  decision-making  process. 

Technical  Objective 

The  primary  objective  was  to  develop  and  formatively  evaluate  primary  staff  and 
stafFgroup  training  modules  using  the  Staff  Group  Trainer  technology  at  battalion  and 
brigade  levels  for  movement  to  contact,  deliberate  attack,  and  defense  missions. 


Scope  of  the  Project 

The  Staff  Group  Trainer  Project  developed  a  battalion  and  a  brigade  staff  training 
program.  The  training  programs  used  a  modified  SIMUTA  C/ST  hardware/software  package  to 
support  delivery  of  the  training.  The  training  approach  focused  on  the  performance  of  individual 
staff  members,  staff  groups  (e.g.,  Intelligence  Officer  [S2]  and  Operations  Officer  [S3]),  and  the 
integration/synchronization  of  the  primary  battle  staff  during  the  execution  phase  of  the  scenarios. 
Each  scenario  used  the  SIMBART  and  SIMUTA-B  orders  developed  for  the  VTP.  These 
scenarios  were  based  on  at  least  one  battalion  operating  east  to  west  in  the  central  corridor  of  the 
National  Training  Center  at  Fort  Irwin,  California.  The  enemy  forces  were  the  same  as  those  in 
the  SIMBART  and  SEMUTA-B  scenarios  and  were  based  on  the  heavy  opposing  force  units  at 
the  Combat  Training  Centers  and  in  the  U.S.  Army  Training  and  Doctrine  Command  (TRADOC) 
(Department  of  the  Army,  1993b,  1993c).  Each  exercise  took  less  than  an  hour  of  actual 
execution  time.  Each  was  preceded  by  a  preview  and  preparation  phase  that  did  not  exceed  an 
hour  and  was  followed  by  a  structured  AAR  of  less  than  an  hour.  The  training  programs  included 
train-the-trainer  components,  TSPs,  and  preview  and  AAR  support  materials. 


5 


Organization  of  the  Report 


The  remainder  of  this  report  contains  the  following  sections: 

Design  -  A  description  of  the  training  program  design  including  decisions  that  were  made 
and  rationales  for  those  decisions. 

Software  Development  -  The  methodology  and  decisions  involved  in  modifying  the  system 
software. 

Exercise  Development  -  A  description  of  how  the  exercises  were  developed,  decisions 
made  during  the  development,  and  the  internal  formative  evaluation. 

Training  Support  Package  Development  -  A  discussion  of  the  process  for  developing  the 
TSPs,  including  decisions  made  and  results  of  reviews  of  the  initial  products. 

Formative  Evaluation  -  A  description  of  the  formative  evaluation  process  followed  in  the 
project  and  a  summary  of  key  findings  during  external  tests  of  the  training  program. 

Lessons  Learned  -  A  summary  of  the  most  important  lessons  learned  during  the  project. 

Conclusions  -  The  findings  and  suggestions  for  continued  research. 


DESIGN 
Design  Principles 

The  Staff  Group  Trainer  Project  development  team  designed  the  TSPs  for  the  staff  to  have 
a  high  likelihood  of  success  in  each  exercise.  Research  in  adult  learning  and  staff  training  support 
this  design  objective.  Olmstead  (1992)  pointed  out  that  other  researchers  (Mills,  1967;  Gill, 

1977)  found  that  nothing  contributed  more  to  greater  cohesiveness  than  a  successful  action. 

Thus,  the  team  developed  the  training  programs  so  that  for  each  exercise,  the  staff  would  be 
challenged  but  should  successfully  achieve  the  exercise’s  training  objectives.  Druckman  and 
Bjork  (1994)  wrote  that  “self-confidence  is  a  potent  predictor  of  an  individual’s  performance”  (p. 
202)  and  that  the  role  of  an  instructor  is  “to  develop  and  sustain  a  learner’s  high  level  of  self- 
confidence  by  ensuring  performance  success”  (p.  202).  Jourdan,  Bandura,  and  Banfield  (1991) 
suggest  that  when  first  teaching  a  complex  task,  a  learner’s  self-confidence  beliefs  and  perception 
of  success  are  enhanced  by  emphasizing  process-related  (learning)  goals  over  outcome-related 
(performance)  goals.  Success  is  redefined  to  include  effort,  form,  and  strategy,  rather  than 
winning  or  losing  or  number  of  tasks  completed  (Jourdan  et  al.  1991). 

Designing  exercises  that  are  both  challenging  and  provide  a  high  likelihood  of  success  is  a 
formidable  task.  The  task  is  to  design  exercises  where  the  challenge  of  a  task  matches  the  ability 
of  the  participants,  so  that  they  become  absorbed  “in  the  game.”  This  is  referred  to  as  “flow” 
(Martens,  1990).  On  one  side  of  the  “flow”  state  is  frustration  because  a  task  is  too  challenging; 
on  the  other  side  is  boredom  when  the  task  is  too  easy  (see  Figure  2).  Within  the  “flow”  state,  the 
training  challenges  the  participant  but  he  experiences  success.  Martens  stated  that  the  participant 
becomes  caught  up  in  or  “immersed”  in  the  activity  when  the  “flow”  state  is  achieved.  This  could 
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be  similar  to  Brown’s  (1992)  concept  of  immersion.  While  designers,  developers,  and  trainers 
strive  to  achieve  this  “flow”  state  in  training,  it  is  complicated  because  staffs  and  staff  sections  are 
often  not  at  the  same  level  of  training.  Providing  “flow”  exercises  for  all  requires  a  robust  training 
environment.  The  training  matrix  conceptualized  at  the  beginning  of  this  project  to  provide  this 
robustness  is  discussed  later. 


Figure  2.  The  relationship  between  challenge  and  ability:  The  “flow"  experience 
(This  figure  is  from  Martens,  1990,  p.  45.). 

The  development  team  designed  the  AARs  and  trainer  instructions  so  that  feedback  to  the 
staff  focused  on  performance  of  staff  actions  and  was  provided  positively-praising  good 
performance  and  avoiding  harsh  criticism  of  poor  performance.  During  feedback  sessions, 
Johnson  and  Johnson  (1994)  emphasized  that  team  members  must  process  how  they  are 
functioning  as  a  team,  examine  what  actions  were  helpful  and  not  helpful,  and  make  decisions 
about  what  they  want  to  continue  or  change. 

The  development  team  designed  the  training  to  foster  team  cohesiveness.  Training  a  staff 
requires  staff  members  to  be  able  to:  (a)  individually  make  decisions  by  processing  system- 
specific  knowledge  and  (b)  function  as  members  of  a  team  sharing  individual  knowledge  and 
conclusions,  then  processing  pooled  information  into  system-wide  decisions  (Druckman  &  Bjork, 
1994).  According  to  McIntyre  and  Salas  (1995),  “tactical  teams  within  the  military  exist  (1)  to 
help  a  leader  assess  a  given  scenario  involving  imminent  danger  or  threat,  (2)  to  provide 
information  to  the  leader  in  a  form  that  he  or  she  can  use  in  making  a  decision,  and  (3)  to 
implement  the  action  implied  by  the  decision  that  the  leader  comes  to”  (p.  9).  Orasanu  and  Salas 
(1993)  discussed  a  concept  of  “shared  mental  models.”  A  shared  mental  model  is  organized 
knowledge  shared  by  team  members  who  work  together  over  relatively  long  periods  of  time. 
According  to  Orasanu  and  Salas  (1993,  p.  7),  “such  knowledge  enables  each  person  to  carry  out 
his  or  her  role  in  a  timely  and  coordinated  fashion,  helping  the  team  to  function  as  a  single  unit 
with  little  negotiation  of  what  to  do  and  when  to  do  it.”  U.S.  Army  doctrine  establishes  a  basis 
for  a  staffs  “shared  mental  model”  (Department  of  the  Army,  1988a;  1988b;  1988c;  1988d;  1992; 
1993d).  The  Staff  Group  Trainer  Project  development  team  designed  the  TSPs  so  that  leaders 
would  reinforce  this  model.  Orasanu  (1990)  found  that  leaders  of  high-performing  teams  stated 
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more  plans,  considered  more  options,  provided  more  explanations,  and  sounded  more  warnings  or 
predictions.  The  TSP  design  concept  was  built  on  this  research  background  and  Army  doctrine, 
and  it  formulated  conditions  to  guide  the  staff  to  develop  a  “shared  mental  model.”  The 
development  team  also  established  training  objectives  that  emphasized  process-related  goals 
(Jourdan  et  al.  1991). 

To  embed  these  design  concepts  in  the  TSPs,  the  development  team  designed  the  TSP  to 
allow  leaders  to  communicate  expectations  for  what  was  required  from  the  staff/sections  prior  to 
the  start  of  an  exercise.  Thus,  at  the  start  of  an  exercise,  leaders  communicated  plans,  options, 
explanations,  warnings,  and  predictions  for  the  exercise.  Because  of  leader  involvement  in  the 
training,  leaders  could  reinforce  or  expand  upon  what  they  wanted  to  see  during  exercise 
execution.  Because  training  exercises  portrayed  a  unit  successfully  conducting  its  mission,  the 
development  team  provided  message  traffic  to  the  staff  that  showed  subordinate  units  were 
successful.  During  each  exercise,  the  training  staff  had  a  high  likelihood  of  achieving  the  training 
objectives.  To  further  encourage  this,  the  basic  message  list  from  the  subordinate  and  higher  units 
or  staffs  provided  an  accurate  and  timely  picture  of  the  battlefield.  Messages  were  regulated  so 
that  the  staff  had  adequate  time  to  perform  required  tasks. 

The  development  team  designed  the  AAR  to  focus  on  processes  and  what  did  and  did  not 
work.  As  suggested  by  Johnson  and  Johnson  (1994),  observers  facilitated  the  staff  formulation  of 
what  to  continue  (sustain)  or  change  (improve). 

Training  Concept 

The  Staff  Group  Trainer  Project  plan  was  based  on  an  analysis  of  the  training  gap  between 
BSTS  and  collective  Janus  or  BBS  exercises.  The  development  team  examined  results  of  the 
SIMBART.  trials  (a  structured  Janus  brigade  staff  exercise),  the.  SIMUTA  Janus  trials  (structured 
Janus  battalion  staff  exercises),  BSTS  courses,  and  the  SIMUTA  C/ST  exercises.  They 
determined  that  SIMUTA  C/ST  exercises  would  not  provide  the  staff  sections  and  CPs  the 
interactive  train-up  they  would  need  prior  to  a  Janus  or  BBS  exercise. 

As  a  result  of  this  analysis,  a  new  concept  emerged,  involving  more  than  the  primary  staff 
officers.  The  training  became  oriented  toward  the  staff  section,  the  CP,  and  the  unit  staff  as  a 
synergistic  team.  For  this  effort,  the  development  team  adopted  the  definition  of  “team”  used  by 
Morgan,  Glickman,  Woodard,  Blaiwes,  and  Salas  (1986,  p.  4),  “...a  distinguishable  set  of  two  or 
more  individuals  who  interact  interdependent^  and  adaptively  to  achieve  specified,  shared,  and 
valued  objectives.”  This  shift  in  focus  was  the  impetus  to  change  the  project  name  from  C/ST  to 
Staff  Group  Trainer.3  The  revised  Staff  Group  Trainer  concept  highlighted  how  staff  officers 
would  evaluate  the  information  and  make  decisions  on  mission  impact,  and  then  take  action  on 
their  analysis.  The  new  concept  expanded  the  training  audience  to  include  at  least  two  additional 
members  per  section.  These  individuals  assisted  and  freed  that  section’s  officer  to  perform  the 


3  Although  not  actually  adopted  until  this  project  was  underway,  the  term  Staff  Group  Trainer  will  be  used  for  the 
project  from  this  point  forward.  This  highlights  the  change  in  focus  from  the  SIMUTA  C/ST  project. 
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higher  order  staff  tasks  and  interact  with  other  sections  as  the  training  expanded  into  a  decision¬ 
making  exercise. 

The  TSP  structure  was  organized  in  tables.  Tables  consisted  of  several  modules,  each 
containing  several  exercises.  Figure  3  illustrates  the  battalion  TSP,  while  Figure  4  illustrates  the 
brigade  training  program.  The  entry  point  for  all  staff  sections  was  their  first  exercise  in  the  staff 
section  table.  Each  section  had  its  own  module  consisting  of  two  exercises.  In  the  battalion 
program,  the  section  modules  were  conducted  concurrently.  In  the  brigade  program,  the  main  CP 
and  tactical  command  post  (TAC  CP)  section  modules  were  conducted  concurrently.  The  rear 
CP  modules  were  conducted  at  a  different  time  because  there  were  not  enough  workstations  to 
conduct  all  sections  concurrently.  For  both  the  battalion  and  brigade  TSPs,  each  CP  had  its  own 
training  module.  Both  the  brigade  and  battalion  TSPs  contained  three  exercises  per  CP  module. 
The  C2  tables  in  both  programs  consisted  of  three  modules— movement  to  contact,  deliberate 
attack,  and  defense  (battalion  defense  in  sector  and  brigade  area  defense)  missions.  In  the 
battalion  TSP  both  CPs  participated  in  each  module.  Each  module  in  the  battalion  TSP  consisted 
of  four  exercises.  In  the  brigade  TSP  only  two  of  the  three  CPs  could  participate  in  each  module. 
The  command  group  and  TAC  CP  participated  in  the  movement  to  contact  module.  The  main 
and  rear  CPs  participated  in  the  deliberate  attack  module.  The  TAC  and  Main  CPs  participated  in 
the  area  defense  module.  Each  module  in  the  brigade  program  consisted  of  two  exercises. 

The  remainder  of  this  chapter  discusses  the  program  design  in  terms  of  the  training 
audience,  the  training  system  (hardware  and  software),  training  objectives,  evolution  of  the 
training  matrix,  the  training  team,  and  phases  of  an  exercise. 
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Figure  3.  Battalion  training  program 


Figure  4.  Brigade  training  program 


Training  Audience 


The  development  team  designed  each  TSP  for  a  staff  initially  at  a  “crawl”  level  of  training. 
Such  a  staff  would  be  inexperienced  in  working  with  one  another  or  be  having  difficulty  working 
together.  This  does  not  imply  that  individual  staff  members  would  be  untrained  but  that,  as  a 
collective  section,  the  staff  is  at  the  “crawl”  level  of  their  training.  In  fact,  each  staff  member  was 
assumed  to  be  knowledgeable  of  his  job.  The  development  team  profiled  the  training  audience  as 
members  of  an  active  or  reserve  conventional  heavy  maneuver  battalion  or  brigade  staff.  A 
conventional  unit  was  one  equipped  with  fielded  digital  equipment  (i.e.,  current  maneuver  control, 
field  artillery,  intelligence,  and  combat  service  support  systems)  but  no  experimental  digital 
equipment.  The  training  audience  was  defined  as  individual  staff  members,  staff  groups  (e.g., 
members  of  the  S2  and  S3  sections),  and  primary  battle  staff.  The  training  audience  includes 
those  staff  members  who  routinely  work  in  one  of  the  unit’s  CPs — see  Table  1  and  Table  2.  The 
commander  and  the  S3  are  not  included  in  this  training  audience.  The  commander  and  the  S3,  but 
especially  the  commander,  are  involved  in  the  TSPs  as  trainers  and  unit  standard  setters. 

Table  1 

Battalion  Training  Audience 


Command  Post 

Section 

Training  Personnel 

Executive  Officer  (XO)/Battle  Captain  (BC) 
Assistant  S3 

Operations  Section 

Operations  Non-Commissioned  Officer 
(NCO) 

-  •  '  ' 

Operations  Assistant  -  -  -  -  -  -  - 

S2 

Main 

Intelligence  Section 

Intelligence  NCO 

Command  Post 

Intelligence  Specialist 

Fire  Support  Officer 

Fire  Support  Element 

Fire  Support  NCO 

Fire  Support  Specialist 

Engineer  Officer 

Engineer  Section 

Engineer  NCO 

Engineer  Specialist 

Logistics  Section 

Logistics  Officer  (S4) 

Supply  NCO 

Combat  Trains 

Personnel  Section 

Personnel  Officer  (SI) 

Command  Post 

Assistant  Personnel  Staff  Non- 
Commissioned  Officer  (PSNCO) 

Battalion  Maintenance  Section 

Maintenance  Officer/NCO 

Maintenance  Administration  Specialist 

Medical  Platoon 

Medical  Officer/NCO 

Medical  Administration  Specialist 
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Table  2 

Brigade  Training  Audience 


Command  Post 

Section 

Training  Personnel 

S3  (Officer  in  Charge  [OIC]) 

S3  Air 

Operations  Section 

Assistant  Operations  NCO 

Operations  Assistant  (optional) 

Tactical  Command  Post 

Intelligence  Section 

Tactical  Intelligence  Officer 

Senior  Intelligence  NCO 

Fire  Support  Element 

Assistant  Fire  Support  Officer  [FSO] 
Fires  Support  Specialist 

XO  or  Battle  Captain 

Assistant  S3 

Operations  Section 

Operations  NCO 

Operations  Assistant 

S4  Representative 

Main  Command  Post 

S2 

Intelligence  Section 

Intelligence  Sergeant 

Assistant  S2 

Fire  Support  Officer 

Fire  Support  Element 

Fire  Support  NCO 

..  ,  .  .  . 

Fire  Support  Assistant 

Engineer  Section 

Engineer  Officer 

Engineer  NCO 

Logistics  Section 

S4 

Senior  Supply  NCO 

SI 

Rear  Command  Post 

Personnel  Section 

Medical  NCO 

PSNCO 

Support  Operations  Section 

Forward  Support  Battalion  (FSB) 
Operations  Officer 

Assistant  FSB  Operation  Officer 
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Training  System 


Initially  the  Staff  Group  Trainer  hardware  suite  consisted  of  six  Sun  SPARC  workstations 
linked  by  a  local  area  network  (LAN).  Two  workstations  were  added  later  in  the  project.  Each 
workstation  consisted  of  two  19-inch  color  monitors,  a  keyboard,  a  processor,  and  a  mouse.  A 
military  tactical  map  was  displayed  on  the  left-hand  monitor.  A  message  display  was  on  the  right 
monitor.  One  workstation  was  used  to  control  the  exercise.  When  an  exercise  was  executed,  this 
workstation  sent  pre-scripted  messages  from  the  exercise  message  database  over  the  LAN  to  the 
other  workstations.  One  or  two  workstations  were  allocated  for  support  personnel  role-playing 
subordinate  units  or  staffs  and  higher  headquarters.  The  remaining  workstations  were  allocated 
across  the  staff  positions.  The  system  also  had  a  large  screen  monitor  that  was  used  to  display  the 
main  CP’s  situation  map.  Each  staff  section  in  the  main  CP  could  update  information  to  this 
situation  map. 

The  allocation  of  workstations  varied  depending  upon  what  staff  positions  were  trained  in 
a  given  exercise.  These  workstations  emulated  the  staff  section’s  mapboard,  staff  journal,  files, 
and  all  forms  of  communication  devices  the  staff  section  might  have  (i.e.,  radios,  faxes, 
telephones,  fielded  digital  systems,  etc.).  The  messages  from  the  control  station  were  addressed 
to  specific  stations  (i.e.,  S2,  commander,  etc.).  Each  workstation  displayed  only  the  messages  (a) 
addressed  to  the  staff  section  using  the  workstation  or  (b)  available  via  network  distribution.  The 
LAN  permitted  staff  members  at  the  different  workstations  to  exchange  information.  Additional 
reports  could  be  created  and  received. 

The  two  main  components  of  each  workstation  were  the  tactical  map  display  and  the 
message  display.  The  map  display  gave  each  staff  section  the  ability  to  tailor  the  map’s  scale  and 
features  to  meet  their  needs.  The  section  could  create,  display,  and  edit  various  operational 
overlays  on  the  map  display.  This  enabled  the  staff  section  to  maintain  the  same  type  of  map-  ~ 
based  information  as  they  would  in  a  CP.  The  message  display  indicated  incoming  reports  and 
allowed  the  section  to  open  a  message  to  read  its  contents.  Messages  were  displayed  in  standard 
message  formats.  The  staff  section  could  also  store,  recall,  compose,  transmit,  forward,  and 
annotate  messages  on  the  workstation. 

The  team  developed  software  modifications  to  enhance  some  of  the  functional  features 
and  to  make  the  system  more  reliable  and  easier  to  use.  These  modifications  are  discussed  in 
more  detail  in  the  software  development  section. 

Training  Objective  Development 

The  training  objectives  for  the  Staff  Group  Trainer  represented  an  evolution  from  the 
work  completed  within  the  SIMBART  program  and  incorporation  of  the  BF  analyses. 

The  SIMBART  development  team  devised  a  means  of  focusing  on  staff  activities  that 
supported  the  commander’s  decision  points  (Roger,  Long,  Britt,  Sanders,  Broadwater  &  Brewer, 
1996).  The  team  drew  heavily  on  Olmstead’s  (1992)  adaptation  of  Schein’s  (1965)  adaptive- 
coping  cycle  which  looked  at  organizational  process.  Schein  (1965)  suggested  this  cycle  as  a 
sequence  of  activities  used  by  organizations  in  adapting  to  changes  in  their  environments. 
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Olmstead  (1992)  adapted  this  cycle  to  identify,  isolate,  and  evaluate  staff  processes.  Olmstead’s 
adaptation  is  shown  as  the  inner  cycle  in  Figure  5.  The  SIMBART  cycle  is  the  second  ring  in 
Figure  5.  The  SIMBART  team  referred  to  this  as  “greening”  or  changing  the  terminology  to 
Army  terms  rather  than  academic  terms.  The  SIMBART  development  team  established  an 
observation  and  feedback  system  that  focused  on  these  staff  processes,  and  although  some 
difficulties  arose  with  the  implementation  during  the  pilots  and  trial,  the  design  was  an  effective 
way  to  quantify  staff  performance. 

The  Staff  Group  Trainer  Project  development  team  focused  on  training  the  staff  to  meet 
the  commander’s  needs  on  staff  processes  and  products.  The  development  team  also  examined 
the  BFs.  The  BF  analyses  fit  well  into  the  staff  process  model  developed  in  SIMBART.  With  a 
few  changes  and  adjustments,  the  development  team  modified  the  SIMBART  cycle  into  the  cycle 
shown  as  the  outer  ring  in  Figure  5.  This  cycle  defined  the  training  objectives  for  the  exercises. 

The  training  objectives  evolved  as  the  project  matured.  Initially,  only  five  training 
objectives— process,  analyze,  coordinate,  integrate,  and  recommend— were  listed  in  the  training 
program.  By  the  end  of  the  project  design  phase,  all  ten  training  objectives  were  included  in  the 
program.  Table  3  shows  the  training  objectives  as  they  appeared  in  the  final  TSPs. 

Training  Matrix  Evolution 

The  concept  for  the  project’s  training  matrix  originated  with  Lieutenant  General  Frederic 
Brown  (Retired)  at  the  SIMUTA  proof-of-concept  test  when  he  referred  to  C/ST  as  the  “staff 
conduct-of-fire  trainer  (COFT)”  .  The  development  team  conceptualized  a  matrix  that  progressed 
from  the  staff  section  to  CP  and  then  to  the  staff  in  multiple  CPs.  This  sequence  enabled 
individual  staff  officers  to  progress  from  individual  tasks  to  full  staff  exercises.  This  conceptual 
matrix  became  the  foundation  for  the  design  and  development  of  each  training  program.  Each 
block' In  the  matrix  represented  a  single  exercise.  The  version,  shown  in  Figure  6,  bears  a 
similarity  to  the  unit  COFT  training  matrix  (General  Electric,  1985).  There  were  three 
dimensions— training  complexity  (X-axis),  mission  complexity  (Y-axis),  and  simulation  intensity 
(Z-axis). 

Training  objectives  became  more  complex  from  the  staff  section  table  to  the  C2  table  along 
the  X-axis  (from  left  to  right  in  Figure  6).  In  Tables  4  and  5,  the  training  objectives  are  ordered  in 
the  left  column.  These  tables  illustrate  the  progression  within  the  battalion  and  the  brigade 
programs,  respectively.  Note  that  early  exercises  focused  on  first  training  objectives— monitor, 
process,  and  analyze— while  the  C2  table  focused  on  later  training  objectives  of  direct, 
synchronize,  and  disseminate. 
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Figure  5.  Evolution  of  the  staff  support  cycle. 


Olmstead 


Figure  5.  Evolution  of  the  staff  support  cycle. 


Table  3 


Training  Objectives  for  Battalion  and  Brigade  Training  Programs 


Training  Objective  Description 


Monitor  unit  operations 


Process  information  and 
messages 


Analyze/evaluate 
information 
Communicate  mission 
critical  information 


Coordinate  information 
and  intelligence 
Integrate  staff  input 


Recommend  a  course 
of  action 
Disseminate 
commander’s  decision 
Synchronize  activities  of 
subordinate  and 
supporting  units. 

Direct  BOS  assets  to 
support  commander’s 
intent 


Each  section  actively  seeks  information  about 

•  higher, 

•  adjacent, 

•  support  and 

•  subordinate  units. 

Each  section  acquires  information  by 
listening  to  reports  and 
asking  for  needed  information. 

Each  section 

•  collates, 

•  transforms,  and 

•  organizes  information. 

Each  section  stores  information  on 

•  maps, 

•  situation  boards, 

•  journals,  and 

•  files. 

All  information  can  be  retrieved  and  used. 

Each  section  attaches  meaning,  either  speculative  or  confirmed,  to  information  that 
has  been  acquired. 

Each  section  transmits  information  or  intelligence  to  those  who  must  make 
decisions  about  or  act  on  it.  This  includes  initial  transmittal  of  sensed  information; 
relaying;  and  disseminating  throughout  the 

•  staff, 

•  command  posts,  . ,  -  -  -  * . 

•  subordinate  units, 

•  supporting  units,  and 

•  higher  headquarters. 

Each  section  exchanges  and  discusses  information  and  intelligence  with  others 
outside  the  section  to  clarify  meaning  and  determine  implications. 

The  XO/BC  aids  the  commander’s  battlefield  awareness  by: 
combining  information  and  intelligence  from  all  staff  sections, 
putting  information  and  intelligence  into  a  useable  format,  and 
passing  information  and  intelligence  to  the  commander. 

The  XO/BC  identifies  areas  requiring  staff  sections  to  combine  efforts  to  support 
the  commander’s  intent. 

XO/BC  and  staff  sections  develop  and  analyze  courses  of  action. 

XO/BC  recommends  a  course  of  action  to  the  commander. 

The  staff  prepares  and  issues  orders  or  fragmentary  orders  (FRAGOs)  to  inform 
units  and  staff  of  commander’s  decision. 

The  XO/BC  and  each  section  monitor  unit  and  Battlefield  Operating  Systems 
(BOS)  assets  to  ensure  their  efforts  are  aligned  to  execute  the  commander’s  intent 
or  direction. 

The  XO/BC  and  each  section 
track  activities  of  BOS  assets  and 

intervene,  if  required,  to  ensure  their  activities  support  the  commander’s  intent. 
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The  Y-axis  of  the  matrix  (the  vertical  axis  in  Figure  6)  represented  the  complexity  of  the 
program’s  three  missions.  When  the  development  team  analyzed  these  missions  for  complexity  of 
staff  actions,  they  ranked  the  three  missions  from  simplest  to  most  complex  as  follows: 
movement  to  contact,  deliberate  attack,  and  defense. 

The  Z-axis  (the  front-to-back  axis  in  Figure  6)  represented  simulation  intensity.  The 
original  idea  was  to  vary  not  only  the  number  of  messages  but  also  the  type  of  information  and 
accuracy.  There  would  be  three  different  message  lists-one  with  only  critical  messages,  one  with 
critical  messages  and  other  messages  that  were  not  critical  for  the  section,  and  one  with  critical 
messages,  non-critical  messages,  and  inaccurate  messages.  Progressing  along  the  Z-axis  would 
have  meant  that  the  staff  would  have  to  deal  with  increasing  numbers  of  messages,  as  well  as  an 
increase  in  complexity  of  analysis  because  of  changes  in  the  message  value  and  accuracy.  In  the 
delivered  exercises,  only  accurate  messages  were  included  although  the  list  did  contain  both 
critical  and  non-critical  messages.  Only  accurate  messages  were  included  because  the 
development  team  was  concerned  with  the  workload  at  each  workstation. 

For  this  project,  the  team  did  not  develop  TSPs  for  the  entire  matrix.  The  unshaded 
blocks  in  Figure  6  indicated  exercises  the  development  team  proposed  to  complete  in  this  project. 
The  unshaded  blocks  represented  a  possible  progression  a  unit  would  take  through  the  matrix  to 
complete  the  training.  Figures  3  and  4  (presented  earlier)  showed  the  delivered  programs.  The 
exercises  in  these  programs  corresponded  to  the  unshaded  blocks.  Although  the  conceptual 
matrix  indicated  multiple  entry  points,  the  delivered  training  programs  had  one  entry  point.  The 
staffs  progress  through  the  matrix  would  be  determined  by  its  performance  in  an  exercise. 
Exceptional  performance  would  take  the  staff  into  more  challenging  exercises.  Poor  performance 
would  result  in  a  remedial  exercise.  The  staff  would  progress  to  the  next  table  only  after 
successful  completion  of  the  gate  exercise.  Since  the  entire  matrix  was  not  developed  and  the 
development  team  was  concerned  with  the  workload  at  each  workstation,  the  developed  exercises 
contained  only  accurate  messages. 
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Figure  6.  Training  matrix. 


Table  4 


Battalion  Program  -  Training  Objectives  for  Each  Exercise 
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Table  5 


Brigade  Program  -  Training  Objectives  for  Each  Exercise 
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Training  Team 


The  framework  for  the  TSP  design  was  not  tied  to  the  organization  and  functions  of  a 
specific  training  team.4  The  development  team  configured  a  training  team  composed  of  12 
trainers  for  the  battalion  program  (Table  6)  and  15  trainers  for  the  brigade  program  (Table  7). 
The  following  paragraphs  summarize  the  role  of  each  training  team  member. 

Table  6 

Battalion  Training  Team 


Title 

Quantity 

Exercise  Director 

1 

Senior  Observer  (Main  Command  Post) 

1 

Intelligence  Section  Observer 

1 

Operations  Section  Observer 

1 

Fire  Support  Element  Observer 

1 

Engineer  Section  Observer 

1 

CTCP  Observer  /Logistics  Section  Observer 

1 

Personnel/Medical  Section  Observer 

1 

Maintenance  Section  Observer 

1 

Interactor 

2 

System  Administrator 

1 

.  . .  .  Exercise  Director  .  ....  . 

The  exercise  director  worked  with  the  unit  commander  before,  during,  and  after  the 
exercise.  The  director  assisted  the  commander  by  helping  him  focus  on  important  issues  that 
occurred  and  ensuring  that  the  training  team  brought  important  information  on  staff  performance 
to  the  commander’s  attention  during  execution.  The  TSPs  contained  materials  that  the  exercise 
director  used  to  assist  the  commander. 

System  Administrator 

The  system  administrator  initialized  the  training  system  and  loaded  the  exercises.  During 
the  exercise,  he  ensured  that  the  messages  were  properly  sent  to  the  workstations  and  took 
immediate  action  should  any  problems  occur.  After  the  exercise,  the  system  administrator  sent 
the  end-of-exercise  (ENDEX)  materials  to  all  the  workstations  and  prepared  the  system  for  the 
AAR  process. 


4  The  training  team  has  been  referred  to  as  an  observer/controller  (O/C)  or  observer/controller/interactor  (O/C/I) 
team  in  other  programs.  This  project  used  the  term  “training  team”  to  reflect  the  team’s  training  focus. 
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Table  7 


Brigade  Training  Team 


Title _ Quantity 

Exercise  Director  1 

Senior  Observer/Main  CP  Observer  1 

Intelligence  Section  Observer  (Main  CP)  1 

Operations  Section  Observer  (Main  CP)  1 

Fire  Support  Element  Observer  (Main  CP)  1 

Engineer  Section  Observer  (Main  CP)  1 

TAC  CP  Observer/Operations  Section  Observer  (TAC  CP)  1 

Intelligence  Section  Observer  (TAC  CP)  1 

Fire  Support  Element  Observer  (TAC  CP)  1 

Rear  CP  Observer/Logistics  Section  Observer  (Rear  CP)  1 

Personnel  Section  Observer  (Rear  CP)  1 

FSB  Support  Operations  Section  Observer  (Rear  CP)  1 

Interactor  2 

System  Administrator _ 1 


Interactors 


. .  Interactors  role-played  as  higher,  lower,  and  adjacent  staffs  communicating  with  the 
training  audience.  During  the  exercise,  the  interactors  responded  to  message  traffic  not  addressed 
to  the  training  audience.  They  kept  the  exercise  director  and  commander  apprised  of  how  the 
staff  was  keeping  higher  and  lower  headquarters  informed  of  the  battle. 

Command  Post  Observers 

One  person  served  as  the  observer  in  the  Main  CP.  In  the  TAC  CP,  Rear  CP,  and  CTCP, 
the  CP  observer  also  observed  one  of  the  sections.  The  CP  observer  monitored  the  interaction 
between  the  sections  within  the  CP.  After  each  exercise,  he  discussed  his  observations  with  the 
officer  charged  with  the  CP’s  operation.  The  CP  observer  in  collaboration  with  the  exercise 
director  facilitated  the  end-of-module  AAR. 

Staff  Section  Observers 

The  training  team  included  a  dedicated  observer  for  every  section  in  each  CP.  This 
arrangement  ensured  that  each  section  was  observed  and  given  feedback  at  the  end  of  every 
exercise.  Individual  section  observers  were  most  important  during  the  initial  tables  where  the 
focus  was  on  the  staff  section’s  performance  of  the  initial  training  objectives. 
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Exercise  Phases 


The  project  design  organized  the  exercises  into  phases  to  facilitate  exercise  development 
and  administrative  control  during  execution.  These  phases  began  when  a  unit  was  at  the  site  and 
had  made  its  preparations  for  conducting  the  training.  Each  exercise  was  broken  into  four  phases: 

•  Exercise  preview, 

•  Exercise  preparation, 

•  Exercise  execution,  and 

•  AAR. 

The  following  sections  discuss  each  phase  and  its  design  basis.  The  methods  for 
developing  the  indicated  materials  are  discussed  in  the  exercise  development  section. 

Exercise  Preview 

Brown  (1992)  wrote  that  setting  the  context  for  a  battle  command  staff  training  exercise 
would  be  a  significant  implementation  challenge.  His  goal  was  to  have  the  staff  immersed  in  the 
battle  context  in  30  minutes  or  less.  He  suggested  that  a  unit  staff  would  have  to  be 
knowledgeable  about  both  the  general  situation  and  the  specifics  necessary  for  “each  individual 
staff  officer  and  small  staff  team  to  fit  in  to  a  fast  moving  situation”  (Brown,  1992,  p.  3-8). 

Brown  envisioned  the  general  situation  summary  to  be  far  easier  than  the  specific  situation  to 
present  to  a  staff.  He  anticipated  the  specifics  to  be  the  most  challenging  to  present,  but  to  have 
the  “highest  potential  for  training  applications”  (p.  3-9). 

The  project  development  team’s  analysis  aligned  closely  with  Brown’s  (1992).  They 
envisioned  the  general  situation  summary  to  be  a  short  battle  summary  to  the  entire  staff, 
consisting  of: 

•  what  had  led  up  to  this  point  in  the  battle, 

•  what  to  expect  in  the  exercise,  and 

•  the  exercise  training  objectives. 

The  developers  designed  the  general  situation  summary  to  be  conducted  by  the  exercise 
director  or  senior  observer  using  a  map  with  appropriate  overlays.  The  commander  could  tell  his 
staff  what  he  expected  from  them  during  the  exercise.  The  commander’s  expectations  consisted 
of  the  critical  pieces  of  information  he  needed  from  the  staff  or  the  fact  that  he  wanted  the  staff  to 
make  a  recommendation  based  on  their  analysis  of  the  situation  when  a  decision  point  was 
reached.  This  approach  was  based  on  Orasanu’s  (1990)  findings  on  leaders  of  high-performing 
teams  and  reinforced  the  “shared  mental  model”  concept  discussed  by  Druckman  and  Bjork 
(1994).  The  developers  allotted  10  minutes  for  the  general  situation  summary  and  the 
commander’s  instructions.  The  developers  also  prepared  a  multimedia  presentation  of  the  general 
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summary  for  several  modules  to  demonstrate  an  alternative  approach  to  delivering  this  portion  of 
the  preview. 

The  specific  situation  was  more  challenging  to  prepare  and  present  to  the  unit.  The  design 
was  structured  so  each  section  observer  could  present  a  separate  section  preview  including 
updated  information  or  charts,  overlays,  journals,  etc.  and  a  verbal  section-specific  situation 
update.  The  section  observer  was  required  to  highlight  the  portion  of  the  decision  support 
template  (DST)  and  execution  matrix  specific  for  the  section  and  any  other  section  specific 
requirements.  The  section  leader  was  allowed  time  to  highlight  his  needs,  other  staff  section 
needs,  and  his  commander’s  needs.  These  needs  were  derived  from  the  section  leaders’  analysis 
of  the  DST,  execution  matrix,  and  guidance  provided  by  the  XO/BC.  This  highlighting  of  needs 
further  supported  the  “shared  mental  model”  concept.  The  exercise  TSP  provided  each  section 
observer  with  his  briefing  and  all  exercise  material  for  his  section.  The  section  observer  was 
allotted  about  10  minutes  for  his  preview.  The  delivery  of  the  preview  was  vital  for  the  unit  to 
achieve  maximum  training  benefit. 


Preparation 

After  the  staff  was  immersed  in  the  situation,  they  were  given  time  to  prepare  for  the 
exercise.  This  included  posting  maps,  updating  charts,  and  coordinating  on  anticipated  actions  for 
the  exercise.  During  this  phase,  the  staff  and  staff  sections  had  to  converge  their  action  plans  with 
the  specific  situations  presented  in  the  previews.  R.  G.  Hoffman  et  al.  (1995)  found  that  units 
participating  in  the  SIMUTA  structured  training  exercises  took  more  time  than  had  been  allocated 
for  the  preparation  phase.  In  this  program,  the  developers  allotted  approximately  10  minutes  for 
the  unit  to  complete  their  preparation.  Although  this  was  an  important  phase,  the  development 
team  recognized  more  time  could  be  used  than  was  allotted.  Therefore,  they  instructed  the 
training  team  to  push  the  staff  to  complete  preparations  within  the  allotted  time. 

Execution 

The  structured  training  design  required  that  a  staff  be  provided  with  cues  during 
execution.  The  quality  of  training  was  directly  related  to  the  number,  timing,  and  fidelity  of  these 
cues.  During  execution  of  an  exercise,  there  were  three  sources  of  cues:  the  system  (or 
interactor),  the  training  team,  or  the  staff.  Two  of  the  three  were  controlled  by  the  system  or  the 
training  team.  For  the  staff  created  cues,  the  TSPs  provided  instruction  to  the  training  team  to 
control  those  cues  that  detracted  from  the  training. 

System  or  Interactor  Created  Cues 

Messages  from  the  message  database  were  the  primary  means  of  providing  cues  to  a  staff. 
These  messages  provided  all  the  critical  information  coming  from  outside  the  staff.  The  number, 
timing  and  fidelity  of  messages  were  critical.  Fidelity  required  doctrinally  accurate  and 
situationally  correct  message  traffic.  Messages  were  presented  in  an  expected  format,  i.e., 
according  to  established  Army  procedures.  Enough  messages  were  presented  to  the  staff  to 
ensure  that  they  could  achieve  the  exercise  training  objectives.  The  messages  were  delivered  so 
that  staff  members  were  not  overwhelmed.  Inherent  in  the  message  delivery  rate  was  the  time 
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required  for  the  staff  to  accomplish  the  training  objectives.  For  example,  when  the  staff  section 
received  key  messages,  it  must  have  sufficient  time  to  analyze  and  communicate  its  analysis  with 
other  staff  sections.  The  development  team  designed  the  system  so  that:  message  formats 
replicated  standard  formats,  the  number  of  messages  was  sufficient  to  provide  the  necessary  detail 
but  not  overwhelm  the  staff,  and  the  exercise  director  could  change  the  delivery  rates  based  on  the 
staff’s  performance. 

Coaching 

In  the  SIMUTA  and  SIMBART  programs,  observers  did  not  follow  the  instructions 
concerning  coaching  the  training  unit  (R.  G.  Hoffman  et  al.  1995;  Koger  et  al.  1996).  Shlechter, 
Bessemer,  Nesselroade,  and  Anthony  (1995)  found  that  observers  coached  more  during  a  unit’s 
early  SIMNET  training  than  in  later  training  exercises.  However,  coaching  incidents  were  below 
the  developer’s  expectations  (R.  G.  Hoffman  et  al.  1995).  Hoffman  attributed  part  of  the  problem 
to  the  need  for  systematic  guidelines  for  each  observer.  The  Staff  Group  Trainer  Project 
development  team  incorporated  such  guidelines  in  observer  checklists.  For  each  exercise,  the 
development  team  inserted  coaching  questions  for  each  key  event. 

Within  a  given  training  exercise,  the  development  team  identified  one  or  more  “teachable 
moments”  (i.e.,  specific,  sometimes  intense,  points  within  a  given  scenario  that  offered  particularly 
valuable  opportunities  for  learning  to  take  place).  As  a  unit  conducted  an  exercise,  each  staff 
section  responded  to  message  cues  that  replicated  the  traffic  precipitated  by  the  flow  of  battle. 
Processing  those  messages  amounted  to  the  mission-specific  action  that  was  required  of  the  staff 
member  (e.g.,  update  the  enemy  situation  based  on  a  report  of  enemy  vehicular  movement).  The 
outcome  that  the  observer  was  prompted  to  look  for  was  grounded  in  the  BFs  that  were  aligned 
with  a  given  staff  cell  or  section.  As  appropriate,  the  senior  observer  could  pause  the  exercise 
momentarily,  without  any  staff  member  leaving  his  position  at  a  workstation,  and  use  the  directed 
questioning  approach  to  cause  the  staff  to  think  about  actions  previously  taken,  or  impending 
actions.  Each  observer  also  could  use  this  directed  questioning  approach  to  cause  his  section  to 
think  about  its  actions.  The  exercise  did  not  have  to  be  paused  to  use  the  directed  questioning 
approach. 

This  technique  of  presenting  one  or  two  focused,  reflective  questions  at  set  points  in  an 
exercise  encouraged  staff  sections  and  individuals  to  think  about  critical  aspects  of  their 
performance.  No  answer  was  necessary,  and  the  exercise  continued.  Coaching  occurred  at  the 
workstation,  limited  distractions,  sped  the  exercise,  and  challenged  staff  members  to  consider 
information  referenced  during  the  end-of-exercise  AAR. 

Each  observer’s  coaching  questions  focused  his  attention  during  the  exercise  and  in 
structuring  the  AAR.  During  the  AAR,  he  obtained  comments  from  the  section  that  promoted 
self-discovery  learning.  By  preparing  expected  responses  to  each  rhetorical  coaching  question, 
the  development  team  created  an  “a-way”  (Brown,  1991)  for  comparison  to  the  unit’s 
performance.  Brown’s  “a-way”  is  not  a  “school  solution.”  It  is  a  way  that  a  successful  staff 
performed  in  the  same  situation.  In  this  program,  this  was  the  way  the  development  team  thought 
a  successful  staff  may  have  performed. 
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After  Action  Review 


One  level  of  AAR  for  all  tables  and  an  additional  level  for  CP  and  C2  tables  was  designed. 
The  first  was  the  section  end-of-exercise  AAR  that  provided  each  section  immediate  feedback  on 
its  performance.  The  staff  section  observer  conducted  these  at  the  section’s  workstation  after  the 
exercise.  The  second  was  the  end-of-module  AAR.  The  senior  observer  or  exercise  director 
conducted  this  at  the  end  of  CP  and  C2  table  modules.  The  end-of-module  AAR  focused  on  CP 
or  staff  processes  and  interactions.  Both  AARs  were  structured  to  facilitate  observer  objectivity. 

Section  End-of-Exercise  After  Action  Review 

The  section  end-of-exercise  AAR  was  divided  into  several  components:  staff  section  self- 
assessment,  previous  action  plan  review,  message  handling  review,  overlay  comparison,  execution 
discussion,  battle  tracking  discussion,  staff  support  process  model  (this  model  is  described  later  in 
this  section)  discussion,  section  action  plan  preparation,  and  coordination  with  other  staff 
sections.  Observers  completed  the  end-of-exercise  AAR  within  30  to  60  minutes,  depending  on 
the  complexity  of  the  exercise  and  the  needs  of  the  staff  section.  To  start  the  AAR,  the  observer 
reviewed  the  purpose  of  the  exercise  and  the  staff  section  s  action  plan  from  the  previous 
exercise,  helped  the  staff  section  focus  on  the  key  performance  issues  from  this  exercise,  and  then 
helped  the  staff  section  determine  areas  needing  improvement.  This  design  had  each  observer 
facilitate  the  staff  section’s  decisions  on  what  to  continue  (sustain)  or  change  (improve)  as 
suggested  by  Johnson  and  Johnson  (1994).  The  observers  emphasized  process-related  training 
objectives  as  recommended  by  Jourdan  et  al.  (1991).  The  emphasis  was  not  on  what  decisions  or 
actions  the  staff  made  but  rather  on  how  decisions  were  reached  or  how  the  actions  were  taken. 

Self  assessment.  At  the  end  of  an  exercise,  the  observer  gave  the  staff  section  an  end-of- 
exercise  action  plan  worksheet  (Figure  7)  listing  objectives  specific  to  the  section.  The  section  as 
a  group  rated  itself  on  each  objective  and  explained  why  they  rated  themselves  as  they  did.  Each 
training  objective  listed  expected  activities  for  the  staff  section  that  were  keyed  to  the  exercise. 

Training  objectives,  tasks  for  the  exercise,  and  action  plan  review.  The  observer  reviewed 
the  training  objectives,  exercise  tasks,  and  section’s  last  action  plan.  The  purpose  of  this  review 
was  to  clarify  the  focus  during  the  AAR. 

Review  of  message  handling.  A  message  summary  review  and  staff  journal  review  were 
designed  to  give  a  quick  synopsis  of  what  the  section  did  with  all  messages  that  came  through  the 
workstation  during  the  exercise.  The  focus  was  not  on  message  content  but  whether  the  staff 
opened  and  read  the  message  and  then  took  action. 
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Figure  7.  Intelligence  section  end-of-exercise  action  plan  worksheet  -  Brigade  Exercise  34. 


Review  of  battle  tracking.  On  the  workstation,  the  observer  brought  up  the  ENDEX 
overlay  and  the  section’s  overlays,  and  provided  the  ENDEX  charts  from  the  TSP.  These  charts 
contained  information  the  staff  section  should  have  tracked  during  the  battle  (i.e.,  unit  strengths 
and  locations,  enemy  strengths  and  locations).  The  observer  provided  the  staff  section  with  the 
starting  information  at  the  beginning  of  the  exercise.  He  and  section  members  then  compared  the 
overlays  and  charts  for  agreements  and  differences  and  determined  causes  and  ways  to  correct  any 
differences. 

Observer  checklist  discussion  and  staff  support  process  model  review.  Each  observer’s 
checklist  was  designed  for  his  section  and  exercise  observed.  This  checklist  had  key  messages  the 
section  received,  expected  staff  actions  on  these  messages,  and  coaching  questions  for  each 
expected  staff  action.  The  observer  used  the  coaching  questions  to  facilitate  staff  section 
discussion.  The  staff  support  process  model  was  a  graphic  depicting  the  relationship  of  a  key 
event  to  all  expected  staff  actions  during  the  exercise.  This  was  used  during  the  discussion  on 
expected  staff  actions.  The  discussion  assisted  the  staff  section  to  decide  how  to  sustain  or 
improve  its  performance  during  the  next  exercise. 

Action  plan  development.  Observers  reviewed  the  previous  action  plan  with  the  staff 
section.  The  section  evaluated  how  it  did  on  that  plan.  The  observer  facilitated  the  section’s 
preparation  of  an  action  plan  for  the  next  exercise. 

Coordination  with  other  staff  sections.  Staff  section  members  communicated  with  other 
staff  sections  to  work  out  areas  of  needed  coordination  discussed  during  the  AAR. 

Staff  Leader  Discussion 

While  staff  sections  conducted  their  end-of-exercise  AARs,  the  commander,  exercise 
director,  senior  observer,  and  XO/BC  discussed  how  the  commander’s  information  requirements 
were  met  during  the  execution.  This  discussion’s  purpose  was  for  the  commander  to  assist  the 
XO/BC  in  understanding  the  commander’s,  higher  headquarters’,  and  subordinates’  information 
requirements,  and  for  the  commander  and  senior  observer  to  provide  feedback  on  how  well  the 
XO/BC  were  filling  those  needs.  (Figure  8  is  an  example  of  the  commander’s  job  aid  supporting 
the  discussion.) 
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AD  Module  Unit  Commander’s  Observations  Worksheet 


Figure  8.  Commander's  observations  worksheet  -  Brigade  Exercise  34  and  35. 


End-of-Module  After  Action  Review 


An  End-of-Module  AAR  was  designed  to  end  each  CP  and  C2  training  module.  This  AAR 
was  conducted  after  the  section  AARs  and  was  limited  to  30  to  60  minutes.  The  exercise  director 
conducted  this  AAR.  As  with  other  AARs,  the  focus  of  this  AAR  was  improving  staff 
performance.  The  staff  left  this  AAR  with  a  plan  to  improve  its  performance  (sustain  its  strengths 
and  improve  where  weaknesses  were  identified). 

The  commander  was  integral  to  the  structured  end-of-module  AAR.  The  exercise  director 
provided  the  commander  a  guide  before  each  exercise  to  focus  him  on  key  activities.  These 
guides  also  focused  commander’s  comments  during  the  AAR.  The  exercise  director,  assisted  by 
the  interactors,  provided  the  commander  an  assessment  of  how  well  the  staff  kept  higher  and 
lower  elements  informed.  After  the  exercise  director  reviewed  the  training  objectives  and  tasks, 
the  commander  explained  how  the  staff  portrayed  the  tactical  situation  and  how  the  staff 
helped/hindered  his  vision  of  the  battlefield,  situational  assessment,  and  actions.  The 
commander’s  comments  complemented  his  after-exercise  discussions  with  the  XO/BC.  The 
commander  focused  on  improvements  the  staff  made  during  the  training.  Prepared  slides  focused 
on  activities  that  occurred  during  the  module  and  assisted  the  commander  in  keeping  his 
comments  focused  on  staff  performance. 

The  design  called  for  the  commander  and  staff  to  complete  the  end-of-module  AAR  by 
assessing  their  own  performance.  A  slide  (multimedia  for  some  exercises)  for  each  facet  of 
performance  was  provided  to  assist  the  commander  and  staff  in  this  assessment.  After  completing 
the  assessment,  the  staff  prepared  an  action  plan  to  sustain  and  improve  performance  during 
follow-on  modules  or  unit  home-station  training. 

SOFTWARE  DEVELOPMENT 

The  project  team  organized  the  software  development  process  into  phases  or  lots.  Lot  1 
allowed  testing  for  the  basics  of  battalion  exercises.  Lot  2  included  modifications  to  support 
testing  of  brigade  exercises.  Lot  3  modifications  enabled  the  development  team  to  test  the 
battalion  and  brigade  TSPs  using  actual  units. 

Methodology 

The  software  development  planning  built  on  the  legacy  code  from  the  CVCC  and 
SIMULA  C/ST  projects.  Therefore,  only  modifications  and  enhancements  were  considered. 
Initially,  a  list  of  desired  software  modifications  (Table  8)  was  developed.  The  modifications  were 
based  on:  (a)  identified  shortcomings  in  the  legacy  system  which  emerged  during  the  SIMUTA 
C/ST  formative  evaluation  and  (b)  the  project  team’s  experiences  with  the  software.  The  basis  for 
prioritization  was  contribution  to  the  training  objectives  articulated  in  the  program  design.  The 
software  modification’s  final  status  is  shown  in  the  third  column  of  Table  8  labeled  “Delivered.” 

Of  the  items  shown  in  Table  8,  the  three  most  critical  changes  needed  to  improve  system 
capability  were  the  abilities  to:  (1)  use  expanded  radio  nets,  (2)  change  platform  names  from 
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battalion  stations  to  brigade  stations,  and  (3)  display  messages  on  the  screen  in  a  format  consistent 
with  tactical  standing  operating  procedures  (TSOP). 

When  the  code  was  examined  closely,  a  determination  was  made  that  it  would  not  be  cost 
effective  to  attempt  only  to  enhance  the  legacy  software.  The  legacy  software  had  been  designed 
to  protect  the  integrity  of  the  system.  The  players  and  radio  nets  were  set  by  the  programmer  and 
could  not  be  modified  by  the  user.  Although  message  contents  could  be  altered  using  the  text 
editor  on  the  Sun  workstations,  the  message  formats  were  custom  designed  in  C  code.  That 
meant  that  even  a  small  change  (e.g.,  have  item  X  appear  as  line  2  instead  of  line  1)  to  a 
previously  coded  message  or  any  new  message  would  require  expensive  programmer  code 
changes.  The  development  team  needed  to  be  able  to  change  messages  and  redefine  nets  and 
platforms  as  the  exercises  were  developed.  In  order  to  change,  the  software  approach  was 
restructured  to  a  data  base  methodology. 

Formative  Evaluation  of  the  Software 

As  each  software  lot  was  delivered,  the  software  was  installed  on  a  stand-alone  Sun 
system.  There,  tests  were  run  to  see  if  expected  performance  standards  were  met.  If  no  problems 
were  encountered  during  this  stand-alone  trial,  the  software  was  loaded  and  tested  on  the 
network.  When  the  pilots  and  the  trials  were  conducted,  the  development  team  asked  individual 
workstation  operators  to  identify  problems  they  encountered  while  using  the  equipment. 


31 


Table  8 


Staff  Group  Trainer  Project  Software  Modifications 


Lot# 

Description 

Delivered 

Yes/No 

1 

Adjusted  message  formats  so  that  more  than  1024  bytes  could  be  sent  in  a 
single  message. 

Yes 

1 

Reformatted  staff  journal  to  resemble  the  standard  Army  form. 

Yes 

1 

Updated  report  formats  and  included  Army  standard  message  priorities. 

Yes 

1 

Provide  capability  to  adjust  exercise  execution  speed.  (Not  delivered  as 
desired  but  allowed  the  development  team  to  change  exercise  speed.) 

Yes/No 

1 

Developed  capability  for  a  workstation  to  annotate  reports. 

Yes 

2 

Modified  station  role  assignments. 

Yes 

2 

Reduced  size  of  minefield  symbol. 

No 

2 

Modified  radio  net  structures  to  handle  various  echelons  and  locations. 

Yes 

2 

Increased  color  palette  so  that  colors  on  the  map  display  corresponded  to 
military  map  colors. 

Yes 

3 

Provided  ability  to  pause  and  restart  the  exercise. 

Yes 

3 

Provided  ability  to  recover  individual  workstations. 

No 

3 

Created  capability  to  send  overlays  from  workstations. 

No 

3 

Replaced  text-based  exercise  summary  with  graphic  of  message  handling. 

No 

3 

Provided  menu  driven  controls  to  systems  administrator. 

...  No . 

3 

Improved  workstation  recovery  capability. 

Yes 

3 

Provided  capability  to  build  database  of  each  session  that  is  keyed  to  staff 
position. 

Yes 

3 

Developed  automated  Take  Home  Package  (on  a  stand-alone  personal 
computer  platform). 

Yes 

NA 

Added  a  100  x  100  km  map  grid  (not  on  the  original  list). 

Yes 

3 

Simplified  the  required  inputs  for  graphics. 

No 

3 

Made  “map  edit”  default  mode  to  make  use  easier. 

No 

3 

Made  “highlight  top”  the  default  status  of  any  overlay  posted  on  top  of  the 
map  display. 

No 

\T 

3 

Added  range  fan  symbols. 

No 
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Key  Software  Enhancements 


This  section  discusses  the  major  software  accomplishments  achieved  during  this  project. 
These  mainly  reflected  the  basic  restructuring  of  the  operational  context  of  the  software.  These 
enhancements  provided  the  most  useful  improvements  to  the  system’s  training  capabilities. 

Changes  to  Message  Formats  and  Editing  Procedures. 

The  system  was  upgraded  to  a  more  flexible  message  input  design.  This  was  part  of  the 
development  of  new  message  formats.  It  provided  the  training  developers  with  a  message  viewer 
similar  to  what  might  appear  in  custom  data  base  forms.  With  this  user-friendly  Graphic  User 
Interface  (GUI)  message  editor,  which  consisted  of  text  boxes  and  pop-up  lists,  the  training 
developer  could  rapidly  and  accurately  input  pre-scripted  messages  needed  to  drive  the  structured 
training.  This  was  a  significant  enhancement. 

Impacts  of  Change 

The  impacts  of  the  change  were: 

•  Decreased  operational  costs  if  fielded.  This  modification  decreased  the  man-hour 
requirements  for  exercise  message  construction  by  a  factor  of  more  than  40-to-l. 

•  Decreased  errors  in  the  message  input  to  the  point  that  messages  could  be  created 
over  a  lunch  hour  and  the  exercise  could  be  run  when  the  staff  returned. 

•  Eliminated  likelihood  of  a  system  crash  due  to  an  improper  message  format. 
Recommended  Improvements 

Capabilities  of  the  message  editor  should  be  expanded  to  include  generating  the  exercise 
message  stream  without  having  to  enter  the  text  editor  on  the  Sun  platform.  This  would  further 
decrease  man-hour  requirements  and  potential  for  error,  while  maintaining  flexibility. 

Station  Roles  and  Radio  Nets 

The  delivered  software  no  longer  required  new  code  and  programmer  assistance  to  modify 
station  roles  and  radio  nets.  This  enabled  training  developers  to  easily  reconfigure  the 
workstations  to  support  various  configurations  necessary  for  the  battalion  and  brigade  TSPs. 

Impacts  of  Change 

The  workstations  could  be  reconfigured  to  accommodate  multiple  CP  configurations.  In 
the  legacy  system  only  one  configuration  was  possible  without  a  programmer  changing  the  code. 
In  the  new  system,  the  system  manager  could  easily  change  the  role  of  any  workstation.  This 
allowed  the  developers  to  modify  the  configuration  for  the  various  levels  (brigade  and  battalion) 
and  CPs  (TAC,  main,  and  rear  CPs  for  the  brigade,  and  main  CP  and  CTCP  for  the  battalion). 
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Recommended  Improvements 

It  is  still  not  possible  to  change  the  radio  nets  a  workstation  receives  as  the  exercise  is 
running.  This  means  that  a  workstation  can  not  switch  from  one  radio  net  to  another  during  an 
exercise.  This  capability  should  be  examined  if  exercises  are  to  contain  training  activities  such  as 
displacement  of  the  main  CP  in  which  responsibility  for  the  execution  of  battle  must  be  transferred 
to  the  rear  CP  and  sections  must  change  the  nets  they  monitor. 

After  Action  Review  Graphics 

The  design  concept  for  AARs  revolved  around  the  actions  taken  by  the  staff  with  regard 
to  “Key  Teaching  Point”  messages  and  staff  actions  needed  to  provide  commanders  with  orders 
and  information  to  correctly  implement  the  commander’s  intent.  The  SIMUTA  C/ST  AAR 
provided  the  training  staff  with  feedback  on  what  actions  were  considered  to  be  doctrinally 
correct  with  respect  to  actions  taken  on  incoming  messages.  All  feedback  was  presented  to  the 
student  in  textual  format.  No  use  was  made  of  the  data  collected  in  the  instrumentation  packages. 
In  this  project,  an  AAR  plot  was  developed  to  graphically  display  the  measurements  collected. 
This  plot  showed  various  parameters  on  message  actions  (e.g.,  messages  annotated,  posting  of 
messages  to  situation  displays,  etc.)  across  time. 

Impacts  of  Change 

The  impacts  of  the  change  were: 

•  Graphic  display  of  performance  trends.  This  allowed  the  staff  section  to  do 
performance  self-assessment  during  the  exercise. 

•  A  more  appropriate  means  of  evaluating  adult  learning. 

•  Direct  application  of  performance  instrumentation  in  a  form  which  was  immediately 
usable  by  staff  sections  and  developers/researchers. 

Recommended  Improvements 

The  AAR  presentation  capability  should  be  modified  to  tie  it  directly  to  the  training 
objectives-particularly  monitor,  process,  analyze,  and  communicate.  This  would  minimize  an 
observer’s  subjective  assessment  and  foster  self  evaluation.  The  AAR  plot  should  contain  links 
with  message  traffic  processed  on  that  station,  so  a  message  may  be  brought  up  and  viewed  while 
the  plot  is  displayed.  The  plot  could  be  expanded  to  incorporate  performance  during  training 
“windows  of  opportunity”  and  include  a  solution  overlay  as  part  of  the  AAR. 

EXERCISE  DEVELOPMENT 

The  development  team  tailored  the  structured,  simulation-based  training  methodology 
(Campbell  et  al.  1995).  The  methodology  was  used  as  a  start,  but  it  was  found  that  the 
methodology  did  not  fit  a  research  and  development  project  with  undefined  technology  or  a 
training  device  without  documented  task  analysis  and  measures  of  performance.  The 
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methodology  was  modified  to  that  shown  in  the  flowchart  in  Figure  9.  One  change  was  to  split 
Phase  4  (Training  Support  Package  Development)  into  Feedback  Materials  Development  and 
Exercise  Materials  Development  phases.  In  previous  projects  (SIMUTA,  SIMUTA-B,  and 
SEMBART),  exercise  material  development  was  not  required  to  the  extent  it  was  in  the  Staff 
Group  Trainer  Project.  For  these  projects,  the  unit  and  interactors  created  the  message  traffic 
from  what  was  unfolding  during  the  simulation.  For  the  Staff  Group  Trainer  Project,  the  project 
development  team  had  to  create  and  then  load  into  the  computer  system  all  messages  that  would 
be  received  by  the  unit  staff. 


Mission  Development 
Develop  Tactical  Scenario 

The  SIMBART  brigade  and  higher  orders  and  the  SIMUTA-B  battalion  orders  were  used. 
Both  of  these  projects  had  developed  complete  orders  and  graphics  packages.  The  SIMUTA-B 
battalion  was  one  of  the  battalions  in  the  SIMBART  brigade.  These  two  sets  of  orders  and  an 
actual  execution  on  Janus  provided  the  training  program  tactical  scenario  and  scenario  events. 

Determine  Tactical  Scenario  Events 


At  the  start  of  the  project,  the  development  team  executed  each  SIMBART  brigade 
mission  on  Janus  and  recorded  the  screen  views  on  videotape.  The  exercise  was  recorded  in  two 
versions:  one  focusing  on  the  battalion  sector  of  the  battle,  the  other  showing  activities  in  the 
brigade  sector.  These  became  the  battles  used  for  the  Staff  Group  Trainer  Project.  The  events  to 
occur  during  tactical  scenarios  were  determined  by  reviewing  the  events  that  occurred  during 
these  Janus  executions. 


*  -  Exercise  Definition  ' 

Determine  Exercise  Training  Objectives 

During  the  project  design  phase,  the  team  selected  a  logical  progression  in  the  training: 
staff  sections,  individual  CPs,  and  multiple  CPs.  This  progression  was  designed  to  prepare  an 
inexperienced  or  poorly  trained  staff  to  conduct  collective  staff  exercises  in  Janus  or  BBS.  Within 
each  training  program  table  and  module,  there  was  a  deliberate  progression  from  exercise  to 
exercise.  Each  exercise  provided  the  staff  an  opportunity  to  practice  and  improve  on  skills  from 
the  previous  exercise  and  added  at  least  one  additional  training  objective. 
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Since  the  training  objectives  were  centered  on  the  staff  support  cycle  (see  Figure  5),  early 
exercises  started  at  the  beginning  of  the  cycle.  Succeeding  exercises  continued  along  this  cycle. 
The  first  three  training  objectives  in  the  cycle-monitor,  process,  and  analyze-did  not  depend  on 
interaction  with  other  staff  sections.  The  staff  section  tables  focused  on  developing  the  ability  to 
perform  these  objectives  within  the  staff  section.  This  allowed  staff  sections  to  be  trained 
independently  but  concurrently  using  the  same  message  list. 

Each  CP  module  consisted  of  three  exercises  (see  Figures  3  and  4).  Because  of  equipment 
limitations,  only  one  CP  was  trained  at  a  time.  The  team  designed  the  first  CP  exercise  to  train 
the  first  three  training  objectives,  the  same  objectives  trained  in  the  last  staff  section  exercise.  The 
middle  exercise  focused  on  communicating  analyzed  information  within  the  CP,  and  to  the 
commander  and  higher  and  lower  elements.  The  last  exercise  in  each  module  was  designed  to  end 
with  the  staff  making  a  recommendation  to  the  commander  concerning  a  decision  point. 

The  C2  modules  varied  between  the  battalion  and  brigade  TSPs.  For  the  brigade,  each 
module  consisted  of  two  exercises.  The  first  exercise  progressed  to  the  recommendation  at  a 
decision  point.  The  second  exercise  started  with  the  commander  making  the  decision  and 
directing  the  staff  to  disseminate  that  decision.  Finally,  the  staff  was  to  aid  the  commander  in 
synchronizing  and  directing  the  actions  of  the  brigade  units. 

For  the  battalion,  each  C2  module  consisted  of  four  exercises.  The  first  two  exercises 
progressed  to  a  decision  point.  The  last  two  exercises  started  with  the  commander  having  already 
made  the  decision  and  the  staff  going  through  the  last  three  training  objectives. 

Select  Mission  Segment  for  Exercise 

. .  .  Exercise  authors  examined  the  tactical  scenario  and  determined  the  specific  time  periods  in 

the  scenario  when  the  training  objectives  could  be  met  for  each  exercise.  They  kept  the  battle 
flow  continuous  for  each  module  if  possible.  This  meant  that  each  exercise  in  a  module  would 
flow  directly  into  the  next  exercise.  This  was  accomplished  for  all  but  one  module— battalion 
defense  in  sector.  For  this  module,  there  was  a  20-minute  gap  between  two  exercises  coinciding 
with  a  break  between  echelons  of  the  advancing  enemy. 

Since  the  development  team  designed  the  staff  section  tables  to  advance  through  only  the 
first  three  training  objectives,  they  restricted  these  exercises  to  periods  in  the  tactical  scenario 
without  enemy  contact— generally  the  early  movement  of  the  brigade  or  battalion  in  the  movement 
to  contact  mission.  They  kept  the  first  exercise  relatively  short  and  simple  so  the  staff  could 
master  the  initial  objectives  and  get  accustomed  to  the  training  system.  The  second  exercise 
began  from  the  end  of  the  first  exercise  and  continued  to  just  before  initial  contact  with  the 
enemy. 


For  the  brigade  CP  and  C2  modules,  the  exercise  authors  selected  a  decision  point  for  each 
module  and  went  backward  or  forward  in  time  from  that  decision  point  to  meet  the  designated 
training  objectives.  For  battalion  C2  modules,  the  exercise  authors  used  doctrinal  phases  as 
described  in  FM  71-2  (Department  of  the  Army,  1988d)  to  determine  the  content  of  the  exercises. 
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Once  each  exercise  author  defined  the  time  period  and  key  events  within  that  time  period,  he 
completed  the  exercise  outlines. 


Staff  Support  Process  Model 

The  staff  support  process  model  was  a  pictorial  showing  an  exercise  key  event  and 
associated  message  traffic  plus  the  minimum  expected  staff  behaviors  (a  sample  is  at  Figure  10). 
The  pictorials  became  training  aids  to  help  the  staff  understand  how  key  messages  prompt  staff 
actions  and  how  sections  combine  pieces  of  information.  It  also  helped  observers  facilitate 
discussion  with  staff  section  members  on  key  events  and  actions. 

Exercise  Materials  Development 

Once  the  exercise  outlines  were  finished,  authors  developed  exercise  materials.  The 
following  sections  describe  the  methods  and  resulting  products. 

Develop  Message  Traffic 

The  team  conducted  a  map  exercise,  augmented  by  the  Janus  videotape,  DST  and 
synchronization  matrix,  to  determine  the  type  of  message  traffic  that  should  be  received  by  the 
training  staff  from  subordinate,  adjacent,  and  higher  units  or  staffs  for  each  scenario.  They  put 
this  information  into  a  message  summary  database.  This  database  included  time,  report  type, 
whether  the  message  was  a  key  message,  originator,  addressee,  radio  net,  message  summary,  and 
a  training  outcome  for  each  message.  After  the  map  exercise,  the  team  developed  message 
summaries  for  each  mission.  Based  on  the  message  summary  database,  the  team  constructed  the 
message  traffic  database.  Using  Janus  videotapes  as  a  reference,  the  development  team  verified 
activities,  times,  locations,  and  strengths  of  both  enemy  and  friendly  units  against  the  estimates 
made  by  exercise  authors. 


Develop  Information  Charts 

To  begin  this  development,  the  team  initially  used  the  set  of  charts  in  Field  Circular  (FC) 
71-6  (Department  of  the  Army,  1985)  as  a  baseline  to  determine  what  information  charts  each 
staff  section  would  maintain.  Examples  of  these  charts  are:  enemy  strength  and  location,  friendly 
strength  and  location,  and  completion  of  elements  of  the  reconnaissance  plan.  Once  the  message 
traffic  for  each  exercise  was  developed,  exercise  authors  prepared  information  charts  for  each 
staff  section.  Authors  prepared  these  charts  for  the  beginning  and  end  of  each  exercise.  They 
obtained  the  beginning  information  by  reviewing  the  Janus  videotape  and  the  message  database  up 
to  the  start  of  the  exercise.  The  ENDEX  charts  were  prepared  by  adjusting  the  charts  based  on 
message  traffic  during  the  exercise.  The  development  team  found  that  information  needed  to 
keep  the  charts  accurate  was  not  always  in  the  message  database.  Each  exercise  author  went  back 
to  the  Janus  videotapes  to  verify  the  required  information.  This  led  to  more  messages  being 
added  to  the  tactical  scenario  and  exercise  message  databases. 
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Figure  10.  Staff  support  process  model  -  Brigade  Exercise  34. 


Develop  Exercise  Graphics 


The  same  procedure  used  to  develop  information  charts  was  used  to  develop  exercise 
graphics.  The  exercise  authors  determined  the  location  of  all  friendly  and  enemy  units  at  the  start 
of  each  exercise  and  created  the  overlay  for  the  workstation  map  display.  Then,  based  on 
message  traffic  and  the  Janus  exercise,  the  location  of  all  units  at  the  end  of  the  exercise  was 
determined.  Often  the  message  traffic  did  not  support  the  ending  location  of  friendly  and  enemy 
units.  Additional  messages  to  support  the  end-of-exercise  graphics  were  created  as  needed. 

Development  of  Feedback  Materials 

Feedback  materials  focused  on  key  events  in  each  exercise.  Each  exercise  was  designed  to 
have  only  two  or  three  key  events.  This  allowed  the  observers  to  concentrate  on  observing  and 
providing  feedback  on  those  key  events. 

Observer  Checklists 

The  observer  checklists  were  designed  to  be  easy  to  use,  focus  only  on  key  events,  and 
allow  the  observer  to  concentrate  on  staff  performance.  For  every  exercise,  authors  developed  a 
checklist  for  each  observer  and  the  exercise  director.  Each  section  observer  checklist  contained 
key  messages  for  the  section,  expected  section  activities,  coaching  cues,  and  a  place  for  observer 
comments  (Figure  1 1).  The  exercise  director’s  checklist  (Figure  12)  focused  on  the  information 
needs  of  the  commander.  This  was  linked  to  the  commander’s  C2  cycle  (see,  assess,  decide,  act) 
(Department  of  the  Army,  1995). 

After  Action  Review  Materials 

The  section  observer’s  AAR  material  consisted  of:  end-of-exercise  action  plan 
worksheets,  observer  checklists,  a  staff  support  process  model,  and  ENDEX  charts  and  overlays. 
All  of  this  material  was  discussed  in  previous  sections. 

The  training  objectives  were  synchronized  with  evaluation  and  feedback  material  during  a 
map  exercise.  During  this  exercise,  team  members  assessed  if  message  traffic,  DST, 
synchronization  matrix,  staff  support  process  models,  and  observer  checklists  were  in  agreement. 
As  a  result,  some  message  traffic  and  checklists  were  revised. 
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Instructions  Use  this  checklist  to  collect  the  unit  commander’s  observations  on  Exercise  34. 


Figure  12.  Exercise  director's  checklist  -  Brigade  Exercise  34. 


TRAINING  SUPPORT  PACKAGE  DEVELOPMENT 


The  TSPs  consisted  of  paper-based  instructions  and  other  non-traditional  components  (the 
computer  program  on  the  training  system,  message  databases,  preview  and  AAR  materials  on 
computer  system).  This  section  focuses  on  the  paper-based  instructions. 

Development  of  battalion  and  brigade  TSPs  evolved  from  lessons  learned  in  previous 
projects-SIMUTA  and  SIMBART.  The  original  Staff  Group  Trainer  Project’s  TSP  design  was 
based  on  the  SIMBART  TSP.  However,  the  mission  volumes  were  modified  because  of  the 
difference  in  the  program  structure.  The  following  organization  was  used: 

•  Volume  I:  Training  Guide, 

•  Volume  II:  Unit  Preparation  Materials, 

•  Volume  III:  Staff  Section  Table, 

•  Volume  IV:  CP  Table,  and 

•  Volume  V:  C2  Table. 

Several  packages  supplemented  these  volumes.  These  materials  included: 

•  Tactical  Materials:  This  volume  contained  all  orders  and  the  TSOP  used  in  the 
program.  The  brigade  Tactical  Materials  contained  the  division  and  brigade  orders 
and  the  brigade  TSOP.  The  battalion  Tactical  Materials  contained  the  brigade  and 
battalion  orders  and  the  battalion  TSOP. 

•  Workstation  Operator ’s  Guide :  This  guide  was  the  same  for  both  TSPs. 

•  System  Administrator’s  Guide:  This  guide  was  the  same  for  both  TSPs. 

•  Train-the-Trainer  Guide :  This  guide  instructed  a  training  team  how  to  administer  and 
conduct  the  battalion  and  brigade  training  programs.  Because  of  differences  between 
the  two  programs,  the  Train-the-Trainer  Guide  supplement  differed  between  the  two 
TSPs. 

•  Program  Highlights:  Because  of  the  differences  between  the  battalion  and  brigade 
programs,  a  separate  program  summary  was  prepared  for  each. 

The  following  sections  highlight  the  TSP  development  process. 

Structured  Writing 

The  structured  writing  methodology  was  used  in  preparing  the  TSPs.  Structured  writing 
emphasizes  (a)  separating  information  into  small  units  by  purpose  and  function  so  it  can  be  easily 
read  and  understood,  (b)  sequencing  information  based  on  its  use  and  need,  (c)  labeling  topics  for 
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easy  scanning,  and  (d)  presenting  information  in  modular  units  so  it  can  be  easily  modified  (Horn, 
1995).  Users  of  the  SIMUTA-B  and  SIMBART  products  reported  that  the  structured  writing 
presentation  made  the  packages  easier  to  use  than  the  more  traditional,  prose-style  approach 
(Graves  &  Myers,  1997;  Koger  et  al.  1996). 

Battalion  Prototype  Exercise  Development  and  Delivery 

The  exercise  outlines  were  used  to  develop  a  battalion  prototype  TSP.  The  battalion 
prototype  package  contained  support  material  for  4  of  the  32  exercises  in  the  battalion  training 
program.  The  prototype  package  included  the  movement  to  contact  module  from  the  C  table. 
These  exercises  allowed  a  comparison  of  the  new  exercises  to  the  SIMUTA  C/ST  exercises.  The 
prototype  provided  sample  materials  for  external  review.  Comments  from  the  prototype  reviews 
are  discussed  in  the  formative  evaluation  section. 

Brigade  Prototype  Exercise  Development  and  Delivery 

The  brigade  prototype  package  included  exercises  14  through  16  (the  main  CP  module  of 
the  CP  table).  The  prototype  contained  all  the  exercise  support  materials  for  these  three 
exercises.  Comments  from  the  prototype  reviews  are  discussed  in  the  formative  evaluation 
section. 


Battalion  Draft  Training  Support  Package  Development 

The  draft  TSP  was  used  and  reviewed  during  the  pilot  and  implementation  trial  and  then 
refined  based  on  user  and  customer  comments. 

The  battalion  draft  TSP  contained  Volumes  I-V  and  the  Tactical  Materials.  Some  of  the 
CTCP  exercise  materials  in  Volume  TV  and  all  of  Volume  V  were  still  being  developed.  The 
Workstation  Operator's  Guide ,  System  Administrator’s  Guide,  and  Train-the-Trainer  Guide 
were  also  delivered  in  the  draft  TSP,  although  some  of  their  components  were  still  being 
developed. 

A  new  document,  Staff  Group  Trainer  Program  Highlights,  was  added  to  the  package. 
The  Highlights  summarized  the  battalion  training  program.  It  became  “tool”  the  VTP 
Observer/Controller  (O/C)  team  had  requested  during  the  prototype  review. 

Brigade  Draft  Training  Support  Package  Development 

The  brigade  draft  TSP  was  structured  similarly  to  the  battalion  draft.  However,  the 
development  team  did  not  prepare  a  brigade  Workstation  Operator 's  Guide  and  System 
Administrator’s  Guide  because  the  functions  were  the  same  regardless  of  echelon.  As  with  the 
battalion  draft  TSP,  the  development  team  prepared  a  Highlights  document  that  summarized  the 
brigade  training. 
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Final  Training  Support  Package  Delivery 

The  final  versions  of  the  battalion  and  brigade  TSPs  were  delivered  after  the  revisions 
resulting  from  the  implementation  trials  were  completed.  Final  development  included  adjusting 
messages  and  overlays  to  better  support  the  exercises,  finalizing  TSP  contents,  and  finalizing  the 
Staff  Group  Trainer  Project  electronic  files. 

FORMATIVE  EVALUATION 

Two  levels  of  formative  evaluation  were  conducted  throughout  the  project— internal  and 
external.  The  external  evaluations  consisted  of  prototype  exercise  reviews,  pilots,  and 
implementation  trials.  Previous  sections  described  the  internal  reviews.  The  following  sections 
describe  the  results  of  the  battalion  and  brigade  prototype  exercise  reviews,  pilot  tests  and 
implementation  trials. 

During  the  external  evaluations,  team  members  collected  feedback  using  a  variety  of 
methods.  For  the  pilots  and  implementation  trials,  team  members  observed  specific  aspects  of  the 
training  implementation  techniques  and  exercise  design.  Immediately  after  each  pilot  and  trial, 
they  compiled  their  observations.  During  the  pilots,  the  team  questioned  the  participants  after 
each  exercise.  At  the  conclusion  of  each  pilot,  they  interviewed  all  participants  as  a  group. 

During  the  trials,  all  training  team  members  completed  questionnaires  and  participated  in  "hot 
washes"  at  specific  points  in  the  training.  Participants  completed  questionnaires  at  the  conclusion 
of  each  module  and  participated  in  a  group  interview  after  the  trial.  Post-trial  group  interviews 
with  the  training  team  during  the  week  following  each  trial  were  conducted.  The  comments  in 
this  section  were  obtained  from  combining  the  information  gathered  from  all  these  methods. 

Prototype  Reviews 

Participants  in  the  battalion  prototype  review  were  representatives  of  the  battalion  VTP 
O/C  team.  Participants  in  the  brigade  prototype  review  were  representatives  from  the  Combined 
Arms  and  Logistics  Centers,  Intelligence  School,  and  the  brigade  and  battalion  VTP  O/C  teams. 
The  comments  on  the  exercises  were  compiled  by  members  of  the  development  team.  The 
following  discussion  lists  significant  points  made  during  the  prototype  review  concerning  exercise 
development. 

The  purpose  of  the  prototype  reviews  was  to  have  potential  users  review  the  training 
program  and  materials.  The  reviews  focused  on  what  the  development  team  could  do  to  make  the 
training  programs  more  effective  and  the  TSPs  more  useful.  Selected  reviewer  comments  are 
discussed  in  the  following  paragraphs. 

The  reviewers  were  concerned  about  the  highly  structured  AARs.  The  development  team 
maintained  that  more  structured  and  prescriptive  AAR  instructions  and  materials  enabled  a  less 
experienced  observer  to  provide  valuable  feedback  to  the  staff  section  he  was  observing.  Final 
testing  during  the  trials  and  subsequent  field  interviews  with  commanders  for  the  follow-on  Staff 
Group  Trainer  Project  confirmed  the  need  for  the  more  structured  AAR  method. 
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Reviewers  questioned  whether  internal  CP  communication  and  coordination  would  be 
conducted  face-to-face  or  through  the  workstations.  The  team  modified  instructions  and 
expanded  the  train-the-trainer  program  and  staff  orientation  to  ensure  the  staff  sections 
understood  that  internal  CP  communication  and  coordination  should  be  conducted  face-to-face. 

Reviewers  were  concerned  about  exercise  speed  and  the  use  of  pauses.  Allowing  the 
exercise  to  be  slowed  to  less-than-real-time  execution,  or  paused,  were  features  not  available  in 
real-life  situations.  The  reviewers  questioned  whether  the  pause  feature  would  ease  the  stress  of 
battle  and  dilute  the  training  value  of  the  exercise.  However,  the  “crawl”  nature  of  the  Staff 
Group  Trainer  Project’s  methodology  argued  that  slowing  exercise  speed  or  pausing  the  exercise 
allowed  staff  sections  more  time  to  learn  the  basics  of  staff  coordination  and  synergy  before 
progressing  to  a  real-time,  more  realistic  exercise,  such  as  Janus  or  BBS  missions. 

In  the  training  program  design  at  the  time  of  the  battalion  review,  a  battalion  staff 
progressed  through  the  training  program  using  the  movement  to  contact  scenario  for  the  staff 
section  table,  the  main  CP  used  the  deliberate  attack  for  its  CP  module,  the  CTCP  used  the 
defense  in  sector  scenario  for  its  CP  module,  and  the  battalion  staff  chose  any  of  the  three 
scenarios  for  the  C2  table.  The  reviewers  believed  it  was  difficult  for  a  unit  to  study  and  be 
prepared  to  execute  all  three  missions.  The  team  changed  the  CP  table  so  that  each  CP  would  use 
the  deliberate  attack  scenario  for  its  CP  modules. 

Workstation  availability  was  addressed  during  the  reviews.  At  the  time  of  the  reviews, 
there  were  only  six  workstations  available.  As  a  result,  some  staff  sections  shared  workstations 
during  the  C2  exercise.  This  was  seen  as  potentially  a  serious  training  problem.  More 
workstations  were  obtained  before  the  end  of  the  project. 

The  reviewers  suggested  improvements  in  the  message  traffic.  These  suggestions  were 
incorporated  into  subsequent  TSPs.  The  reviewers  recommended  that  some  information  on  the 
message  list  be  eliminated.  The  message  list  included  items  that  cued  staff  actions,  actions  that 
staff  members  were  expected  to  perform  when  they  received  messages,  and  the  BF  tasks  on  which 
their  actions  were  based.  All  this  information,  though  useful,  made  the  message  list  lengthy  and 
difficult  to  use.  The  list  was  modified  to  include  only  basic  message  information-time,  whether 
or  not  the  message  was  a  key  message,  report  type,  originator,  addressee,  net  on  which  the 
message  was  sent,  and  message  summary.  The  other  elements  (expected  staff  actions  and  BF 
references)  became  part  of  the  observer  checklists  and  staff  support  process  models. 

The  reviewers  indicated  there  were  redundant  instructions  in  the  TSP  chapters  for 
different  training  team  members.  They  suggested  eliminating  that  redundancy  by  moving 
instructions  and  materials  pertinent  to  all  trainer  positions  into  a  single  section  at  the  beginning. 
The  development  team  used  these  suggestions  in  developing  the  brigade  prototype  exercise 
packages. 

Reviewer  comments  on  the  brigade  prototype  led  to  major  revision  of  the  Training  Guide 
(Volume  I)  and  Unit  Preparation  Materials  (Volume  II)  for  the  draft  TSPs.  Additionally,  the 
reviewers  suggested  that  both  volumes  could  be  presented  in  a  multimedia  format  (e.g., 
videotape,  CD  ROM).  They  felt  the  user  would  prefer  the  multimedia  format  over  reading  the 
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material.  Reviewers  were  enthusiastic  about  observer  checklists  and  staff  support  process 
models.  They  stated  both  should  be  helpful  in  providing  performance  feedback  to  training  staffs. 
They  also  discussed  the  need  for  a  tool  to  capture  the  staff  section  and  CP’s  action  plans  so  that 
the  results  could  be  easily  incorporated  into  the  final  THP. 

Pilot  Tests 

The  development  team  scheduled  each  pilot  test— battalion  and  brigade— for  a  three-week 
period.  A  training  team  was  required  for  the  entire  three  weeks,  while  the  staff  was  required  for 
only  the  second  of  the  three  weeks.  When  the  software  and  exercises  were  not  ready  for  the 
battalion  pilot,  the  team  restructured  the  pilots.  This  restructuring  still  allowed  the  team  to  test 
the  exercises  prior  to  the  implementation  trials.  Each  pilot  was  reduced  to  a  single  week. 

Because  of  scheduling  constraints  with  the  VTP  O/C  team,  the  brigade  pilot  was  conducted  one 
week  followed  by  the  battalion  pilot  the  next  week. 

The  purpose  of  the  pilots  evolved  into  preparation  for  the  implementation  trials.  The 
development  team  crafted  the  following  objectives  for  the  restructured  pilot  tests: 

•  Train  the  VTP  O/C  team  to  operate  the  training  system, 

•  Familiarize  the  VTP  O/C  team  with  the  training  programs,  and 

•  Evaluate  all  exercises  and  materials  scheduled  for  the  trial. 

For  the  brigade  pilot,  the  VTP  O/C  team  served  in  a  variety  of  roles  to  experience  the 
training  from  different  perspectives.  To  start,  the  development  team  delivered  the  workstation 
operator  training  to  the  VTP  O/C  team.  Following  this,  the  development  team  gave  the  VTP  O/C 
team  a  short  orders  briefing  on  each  mission,  then  asked  them  to  review  the  orders  package.  The 
O/C  team  performed  as  workstation  operators  during  the  section  table,  while  the  development 
team  performed  as  staff  officers.  For  the  CP  table,  the  development  team  performed  as 
workstation  operators  while  the  O/C  team  performed  as  staff  officers.  Finally,  for  the  C2  table 
exercises,  the  O/C  team  acted  as  observers  and  the  development  team  role-played  as  the  unit  staflf- 
-both  workstation  operators  and  staff  officers.  This  allowed  the  O/C  team  members  to  gain 
experience  in  all  the  roles  required  for  the  training,  and  participate  in  all  the  exercises  scheduled 
for  the  trials. 

Because  of  lessons  learned  during  the  brigade  pilot,  the  development  team  made  some 
changes  to  the  battalion  pilot.  The  brigade  O/C  team  had  not  achieved  a  full  conceptual  grasp  of 
the  training  until  the  last  day,  when  the  development  team  functioned  as  the  entire  staff  and  the 
O/C  team  functioned  as  observers.  The  development  team  conducted  a  demonstration  at  the 
beginning  of  the  battalion  pilot  for  the  O/C  team  participants.  The  demonstration  appeared  to 
help  the  participants  grasp  the  concept.  This  demonstration  was  added  to  the  train-the-trainer 
program  and  to  the  unit  orientation. 
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Brigade  Pilot  Results 


The  brigade  pilot  was  the  first  opportunity  to  test  the  train-the-trainer  materials.  Though 
limited  in  scope,  the  executed  portion  included  providing  an  introduction  to  the  training  program, 
workstation  operator  and  system  administrator  training,  and  a  review  of  tactical  materials.  The 
workstation  operator  training  was  well  received,  with  the  following  suggestions:  (a)  add  practice 
exercises  to  link  the  individual  workstation  operator  tasks  with  the  workstation  operator  practical 
exercise,  (b)  include  staff  section  officers  in  some  parts  of  the  workstation  operator  training  so 
they  have  prior  knowledge  of  workstation  capabilities  and  limitations  before  executing  the  staff 
section  table,  and  (c)  emphasize  creation  of  new  reports  with  consolidated  information  rather  than 
routine  forwarding  of  received  reports. 

The  VTP  O/C  team  requested  more  combat  service  support  traffic  and  overlays,  engineer 
traffic,  and  intelligence  traffic.  Inconsistencies  between  the  message  traffic  and  overlays  were 
identified  and  marked  for  correction.  The  O/C  team  indicated  that  the  exercises  might  have  too 
much  happening  in  too  little  time  and  thus  be  unrealistic.  However,  the  development  team 
explained  that  the  times  were  based  on  the  same  missions  executed  on  Janus. 

During  the  pilot,  the  training  system  only  had  a  50K  x  50K  map  grid  that  could  be  used  by 
the  brigade  staff.  The  brigade  Janus  exercises  used  a  100K  x  100K  terrain  database  for  the 
simulation.  This  terrain  database  extended  approximately  50K  further  west  and  south  than  the 
50K  x  50K  battalion  terrain  database.  In  the  brigade  Janus  exercises,  the  staffs  used  paper  maps 
for  their  work  and  had  no  interaction  with  the  simulation’s  terrain  database.  Some  of  the  brigade 
area  defense-  and  movement  to  contact-based  exercises  were  conducted  off  Staff  Group  Trainer’s 
50K  x  50K  map  grid.  To  compound  this,  the  intelligence  message  traffic  for  the  brigade  Janus 
exercises  extended  beyond  the  simulation’s  brigade  100K  x  100K  terrain  database.  Since  the 
brigade  staffs  in  the  Janus  exercises  used  paper  maps  this  did  not  present  a  problem  for  them.  In 
the  Staff  Group  Trainer  exercises,  the  staff  used  the  system’s  map  to  track  all  friendly  and  enemy 
units.  As  a  result,  approximately  60%  of  the  enemy  graphics  and  some  friendly  units  were  off  the 
system’s  map.  This  made  it  difficult  for  the  brigade  staff  to  execute  the  exercises. 

Revisions  were  made  to  the  exercises  and  TSPs  to  respond  to  these  comments.  The  100K 
x  100K  map  capability  was  delivered  prior  to  the  brigade  implementation  trial.  The  larger  map 
was  not  required  for  the  battalion  exercises. 

Battalion  Pilot  Results 

The  following  key  issues  resulted  from  the  battalion  pilot: 

•  The  system  administrator  needed  to  be  proficient  to  execute  exercises. 

•  The  demonstration  helped  the  participants  to  grasp  the  training  concept. 

•  The  staff  section  table  needed  to  be  more  challenging. 

•  The  message  traffic  and  overlays  had  to  be  checked  for  accuracy  and  consistency  with 
OPORDs. 
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Where  possible,  modifications  were  made  to  the  TSPs  and  exercises  to  address  these 

issues. 


Battalion  Implementation  Trial 

The  Staff  Group  Trainer  Project’s  hardware  suite  was  moved  to  the  Mounted  Warfare 
Test  Bed,  a  new  software  drop  was  put  on  the  system,  and  two  workstations  were  added  to  the 
system  between  the  pilots  and  the  battalion  trial.  The  train-the-trainer  phase  (including 
workstation  operator  training)  was  conducted  for  the  VTP  O/C  team  during  the  first  week  of  the 
trial.  The  O/C  team  conducted  the  training  for  a  surrogate  battalion  staff  during  the  second  week 
of  the  trial.  During  the  trial,  the  staff  executed  all  staff  section  table  exercises,  the  main  CP 
module,  and  the  C2  table  movement  to  contact  module. 

There  were  software/hardware  problems  resulting  from  moving  the  system,  adding  two 
workstations,  and  installing  a  new  software  change.  The  development  team  was  not  able  to 
resolve  these  problems  until  the  last  day  of  the  trial.  Because  of  these  problems,  the  training 
schedule  was  adjusted.  The  schedule  changes  and  delays  caused  by  the  system  problems 
contributed  to  negative  comments  from  some  staff  members.  In  their  after-trial  responses,  staff 
members  reported  that  the  training  system’s  hardware/software  interfered  with  training,  the 
training  program  was  not  responsive  to  staff  actions,  the  training  program  was  too  complex  and 
too  long,  and  the  message  traffic  did  not  contain  enough  messages  and  contained  too  many 
mistakes.  The  battalion  O/C  team  echoed  many  of  these  comments.  Development  team  members 
observed  many  of  the  same  problems  and  sought  solutions. 

The  development  team  realized  a  number  of  positive  results  from  the  trial.  Based  on 
observations  and  feedback  from  the  participants,  the  following  findings  emerged: 

•  Individual  section  performance  arid  main  CP  interactions  improved. 

•  The  staff  progressed  through  the  staff  support  cycle. 

•  The  observer  checklists  were  relatively  easy  to  use  and  helped  the  observers  keep 
section  AARs  focused  on  training  objectives. 

•  The  staff  support  process  model  proved  to  be  a  useful  tool. 

•  The  discussions  between  the  XO/BC,  commander,  exercise  director,  and  CP  observer 
were  important  in  training  the  XO/BC. 

•  The  importance  of  several  key  players— commander,  exercise  director,  and 
interactors—was  highlighted.  The  commander  must  be  involved  in  the  training.  He 
must  set  the  tone  and  inform  the  staff  of  his  information  needs.  The  exercise  director 
must  assist  the  commander  throughout  the  training.  The  interactor  cell  must  be  staffed 
by  at  least  two  people  in  the  CP  and  C2  modules.  These  two  individuals  must  be 
knowledgeable  about  staff  activities  and  familiar  with  the  exercises. 
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The  end-of-module  AAR  needed  to  be  more  structured  with  additional  training  aids  to 
assist  the  exercise  director  and  commander. 


Brigade  Implementation  Trial 

The  development  team  implemented  some  of  the  lessons  learned  during  the  battalion  trial 
in  time  for  the  brigade  trial.  Added  emphasis  during  the  train-the-trainer  program  was  placed  on 
areas  where  the  training  program  was  not  implemented  as  designed  during  the  battalion  trial.  This 
emphasis  proved  beneficial  as  training  team  members  followed  the  instructions  presented  in  the 
training.  The  team  created  a  multimedia  end-of-module  AAR  presentation  to  help  the  commander 
and  exercise  director  focus  on  the  training  objectives.  A  fire  support  expert  was  also  added  to 
review  all  the  exercises,  add  fire  support  traffic,  and  correct  faulty  message  traffic  and  overlays. 
The  workbooks  and  training  team  materials  were  also  streamlined. 

The  VTP  O/C  team  served  as  the  training  team  for  the  brigade  implementation  trial.  They 
went  through  the  train-the-trainer  phase  (including  workstation  operator  training)  during  the  first 
week  of  the  trial.  The  O/C  team  then  conducted  the  brigade  training  program  the  following  week. 
The  brigade  staff  was  an  ad  hoc  staff  assembled  from  units  at  Fort  Knox,  Kentucky  and 
elsewhere. 

At  the  conclusion  of  the  train-the-trainer  phase,  which  lasted  less  than  three  days,  the 
development  team  obtained  the  VTP  O/C  team  members’  opinions  about  the  program  and 
materials.  The  O/C  team  indicated  that  more  time  was  required  for  them  to  prepare  to  conduct 
the  training.  Their  estimate  was  a  minimum  of  five  days  with  additional  time  required  for  the 
interactors.  They  stated  that  the  training  program  was  overly  complex. 

Members  of  the  ad  hoc  staff  and  O/C  team  were  concerned  that  the  workstation  operator 
training  program  was  not  ensuring  the  operators  would  be  proficient  for  exercise  execution.  The 
development  team  observed  that  a  few  workstation  operators  fell  behind  in  processing  messages 
during  the  exercises.  The  team  noted  that  there  were  too  many  messages  being  forwarded  on  the 
same  net  (repeating  the  same  message  on  the  same  net),  use  of  the  system  to  do  internal  CP 
coordination  when  face-to-face  communication  was  expected,  and  forwarding  of  individual 
messages  rather  than  creating  new,  consolidated  messages  or  providing  the  analysis  of  a  group  of 
messages.  These  practices  all  increased  the  workload  for  each  workstation  operator  and  were 
contrary  to  workstation  operator  training.  Members  of  both  the  ad  hoc  staff  and  O/C  team 
recommended  that  training  audience  members  be  briefed  on  the  workstation  capabilities. 

For  the  brigade  trial,  the  software/hardware  problems  that  had  been  encountered  during 
the  battalion  trial  were  remedied.  There  were  no  software/hardware  problems  to  interfere  with 
training.  In  their  after-trial  responses,  the  brigade  staff  members  and  O/C  team  members  reported 
that  the  training  system  (hardware/software)  got  in  the  way  of  training,  the  training  program  was 
not  responsive  to  staff  actions,  the  training  package  was  too  complex,  and  the  message  traffic  was 
not  adequate  and  contained  mistakes.  The  brigade  staff  members  and  the  O/C  team  members 
reported  the  training  system  got  in  the  way  of  training  because  the  system  was  new  and  the  CP 
environment  was  different  because  all  means  of  external  communication  were  replaced  with  the 
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system.  The  staff  members  wanted  the  CP  environment  to  mirror  the  field  CP  to  include 
configuration  and  equipment. 

The  project  development  team  observed  many  positive  aspects  of  the  program.  Despite 
comments  by  the  participants,  staff  performance  did  improve.  The  developers  noted  that  the  staff 
did  improve  in  monitoring  unit  activities  and  asking  for  more  information  from  the  units 
concerning  their  activities.  Information  was  processed  more  rapidly  and  efficiently,  and  more 
analysis  of  the  information  was  accomplished.  During  early  exercises,  more  messages  were 
forwarded  without  analysis  to  sections  that  had  already  received  them. 
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LESSONS  LEARNED 


This  section  reports  the  major  lessons  learned  by  the  development  team  during  this 
project.  The  intended  audience  consists  of:  (a)  training  developers,  (b)  program  sponsors  who 
allocate  funding  or  training  programs  and  establish  program  goals  and  objectives,  and  (c)  training 
implemented.  These  lessons  describe  problem  areas  encountered,  suggestions  on  how  to  avoid  or 
cope  with  these  problems  and  areas  the  development  team  felt  were  informative. 

This  section  is  organized  based  on  the  phases— analysis,  design,  development, 
implementation,  and  evaluation-in  the  Army’s  Systems  Approach  to  Training  (Department  of  the 
Army,  1988e). 


Analysis 

There  were  four  major  lessons  learned  during  the  analysis  phase  of  this  project.  These 
lessons  learned  dealt  with  training  audience  characteristics,  training  program  goals,  training 
resources,  and  training  objectives.  This  section  discusses  each  of  those  lessons. 

Training  Audience  Characteristics 

During  the  pilots  and  implementation  trials,  branch  school  representatives  and  VTP  O/C 
team  members  challenged  the  training  design  audience  characteristics.  The  development  team 
used  the  training  audience  characteristics  identified  in  the  statement  of  work  (SOW)  at  the 
beginning  of  this  project.  As  a  result  of  these  challenges,  the  development  team  interviewed 
several  brigade  commanders.  These  interviews  validated  the  training  audience  characteristics 
used  in  the  project.  The  lesson  learned  is  that  future  projects  should  include  an  analysis  of 
training  audience  characteristics  and  needs  at  the  beginning  of  the  project. 

Training  Program  Goals 

The  team  established  goals  early  in  the  program  to  guide  the  design,  development, 
implementation  and  evaluation  of  the  training.  Using  these  goals,  the  development  team  created  a 
training  program  to  bridge  a  training  gap  between  individual  skills  and  collective  staff  skills; 
however,  they  discovered  the  training  gap  to  be  greater  than  originally  thought.  The  resulting 
discussion  between  the  sponsor  and  the  development  team  produced  a  shared  understanding  of 
the  training  gap  and  a  refinement  of  the  training  goals-an  understanding  that,  unfortunately,  was 
not  shared  by  all  trainers  and  participants.  Consequently,  the  development  team  learned  the 
importance  of  selecting  trainers  and  participants  for  the  formative  evaluation  phase  who 
understand,  or  “buy  into,”  the  goals  and  purpose  of  the  program.  This  convergence  of 
understanding  is  particularly  important  when  pilot  and  trial  trainers  and  participants  are  not  part  of 
the  intended  audience,  e.g.,  an  actual  unit  staff,  but  are  emulating  that  audience  in  the  evaluation 
exercises. 
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Training  Resources 


During  pilots  and  trials  the  development  team  uncovered  insights  about  module  duration 
and  the  training  team.  Interviews  with  the  brigade  commanders,  verified  these  insights.  If  these 
areas  had  been  uncovered  in  the  analysis  phase  of  this  project  they  would  have  resulted  in  major 
modifications  to  the  project  design. 

Module  Duration 

Comments  received  during  pilots  and  trials  questioned  the  length  of  the  program  and 
modules.  In  interviews  with  brigade  commanders,  commanders  indicated  that  they  could 
accommodate  a  four-hour  block  of  training  for  their  staff  as  often  as  once  a  week  or  as 
infrequently  as  once  a  quarter.  Commanders  suggested  that  blocks  of  training  be  designed  not  to 
exceed  four  hours.  No  time  restrictions  were  considered  in  the  analysis  and  design  phases  of  the 
project.  The  development  team  focused  on  meeting  the  training  objectives.  As  a  result,  modules 
consisted  of  two  to  four  exercises  based  on  the  development  team’s  estimates  of  what  was 
required  to  achieve  the  training  objectives  (see  Table  9). 

Table  9 

Module  Duration 


Number  of  Exercises 

Expected  Length  per 
Module  (Hours) 

Battalion  Training  Support  Package 

Section  module 

2 

4 

CP  module . . .  .  .  ..  . . 

.  3 

8 

C2  module 

4 

12 

Brigade  Training  Support  Package 

Section  module 

2 

4 

CP  module 

3 

6 

C2  module 

2 

6 

As  a  result  of  the  pilots  and  trials,  the  development  team  determined  that  adjustments 
could  be  made  to  reduce  each  module  to  four  hours  or  less.  In  most  cases  this  could  be 
accomplished  by  reducing  the  number  of  exercises  in  a  module.  Each  module  would  typically 
consist  of  two  exercises.  The  second  exercise  would  reinforce  what  the  training  audience  learned 
during  the  first  exercise  and  its  AAR.  These  adjustments  were  not  made  in  this  project’s  training 
program  but  were  suggested  for  follow-on  work. 

The  lesson  learned  was  that  the  duration  of  training  must  fit  into  the  target  audiences’ 
anticipated  time  allocation  for  the  training.  Developers  can  never  ignore  or  discount  available 
training  time.  During  the  analysis  phase  of  training  program  development,  the  training  developer, 
sponsor,  and  potential  user  must  determine  anticipated  training  time  restrictions. 
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Training  Team 


The  training  team  is  a  training  resource  that  influences  the  design  of  a  training  program. 

In  interviews  with  brigade  commanders,  the  commanders  indicated  that  resources  for  a  training 
team  are  very  limited  and  that  any  training  team  for  staff  training  would  probably  come 
predominantly  from  inside  the  unit  headquarters  (battalion  or  brigade).  Training  teams  such  as  the 
VTP  O/C  team  are  typically  not  available  for  a  local  commander’s  staff  training  program  and 
funding  for  travel  to  a  staff  training  site  is  generally  not  available.  Thus,  structured,  computer- 
driven  staff  training  should  be  available  at  the  brigade’s  home  station  and  require  a  minimal 
training  team. 

Reducing  the  personnel  overhead  requirements  for  staff  training  represents  a  significant 
cost  saving  to  the  military.  In  this  project,  only  support  personnel-system  administrator  and 
interactors— did  not  actively  observe  and  provide  feedback  to  the  training  staff.  This  contrasts 
with  a  Janus  exercise  where  support  personnel  can  easily  consist  of  20  to  30  people  in  addition  to 
the  observer  team.  However,  even  the  requirements  for  9  to  12  observers  plus  the  support  staff 
would  still  exceed  the  personnel  immediately  available  to  the  brigade  commander.  Future  efforts 
must  strive  to  reduce  the  training  team  to  numbers  the  brigade  commander  can  support.  The 
training  benefits  or  losses  associated  with  various  training  team  structures  should  be  explored. 

Training  Objectives 

Integration  of  the  Staff  Support  Cycle  into  the  Training  Program 

In  the  SIMBART  program  (Roger  et  al.  1996),  the  SIMBART  Team  had  difficulty  in 
getting  the  O/C  team  to  focus  the  AARs  on  staff  processes.  The  SIMBART  Team  had  not 
integrated  the  SIMBART  staff  support  cycle  (see  Figure  5  earlier  in  this  document)  into  the 
training  objectives  and  observer  checklists.  As  a  result,  the  O/Cs  were  able  to  circumvent  the 
staff  cycle.  During  the  AAR  process  they  did  not  focus  on  the  brigade  staff’s  actions.  In  the  Staff 
Group  Trainer  Project,  the  development  team  further  evolved  and  integrated  the  staff  support 
cycle  into  the  instruction  design.  They  adjusted  the  SIMBART  concept  and  developed  the  staff 
support  cycle  to  include  BF  analyses  tying  training  objectives  with  specific  tasks  and  performance. 
The  cycle  defined  the  training  objectives  for  the  training  programs.  These  objectives  in  turn  were 
used  to  structure  the  observer  checklists  and  AARs.  Because  of  this  integration,  the  training  team 
accepted  the  staff  support  cycle  and  used  it  in  conducting  all  AARs.  The  lesson  learned  is  that  by 
tightly  structuring  the  training  objectives  into  the  trainer  support  materials,  resistance  to 
implementation  as  designed  is  decreased. 
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Measuring  Performance  of  Training  Objectives 

In  this  project,  the  development  team  did  not  quantitatively  analyze  the  training  objectives. 
They  did  refine  the  training  objectives  and  tie  them  more  closely  to  staff  tasks  and  BFs. 

The  first  several  of  these  training  objectives— monitor,  process,  analyze  and  communicate— 
can  be  measured  by  instrumentation  on  the  computer  system.  However,  if  the  Staff  Group 
Trainer’s  computer-driven,  structured  training  environment  is  fielded,  it  must  not  just  claim  to 
train  performance,  it  must  have  developed  and  evaluated  measures  of  performance  for  all  tasks  to 
ensure  that  commanders  can  determine  that  training  does  take  place. 

Design 

It  is  difficult  to  design  exercises  that  train  processes,  and  provide  a  high  likelihood  of 
success,  while  providing  a  challenging  training  progression.  This  section  discusses  major  lessons 
learned  in  the  development  team’s  attempts  to  design  a  program  that  would  meet  this  goal. 
Additionally,  this  section  discusses  the  team’s  use  of  a  shared  mental  model  to  enhance  team 
training. 


Separating  Process  from  Outcomes 

The  AARs  in  previous  SIMUTA  and  SIMBART  staff  training  exercises  were  long  and 
focused  on  battle  outcomes  rather  than  staff  processes  (R.  G.  Hoffinan  et  al.  1995;  Koger  et  al. 
1996;  Graves  &  Myers,  1997).  This  is  typical  of  AARs  for  most  battle  exercises  and  simulations 
where  winning  is  the  objective  not  how  you  play  the  game.  The  Staff  Group  Trainer  is  not  a 
tactical  trainer.  The  exercise  is  information-based.  Battle  scenarios  serve  only  as  the  means  to 
drive  staff  actions.  They  are  designed  to  elicit  individual  and  team  behaviors.  To  train  the  staff  it 
is  necessary  to  focus  on  staff  processes.  The  information  provided  to  the  staff  is  selected  to  paint 
a  picture  which  will  cue  specific  staff  behaviors.  This  information  is  highly  structured.  Observers 
know  when  staff  behaviors  should  occur  and  they  can  focus  on  the  staff  s  reactions  to  these  cues. 

The  development  team  intentionally  designed  the  exercises  to  be  short  to  separate  staff 
processes  and  actions  from  battle  outcomes.  The  staff  acts  and  produces  specific  staff  products. 
But,  the  exercise  is  stopped  before  the  staffs  recommendations  or  products  have  an  opportunity 
to  influence  the  battle  outcome.  While  some  participants  were  disappointed  because  their  actions 
and  products  had  no  impact  on  the  battle,  the  structure  helped  the  training  team  remain  focused 
on  process  during  the  AARs  because  there  were  no  outcomes  to  discuss.  The  development  team 
learned  that  short,  structured  exercises  improved  the  acceptance  of  the  training  focus  on  staff 
processes. 


Training  Progression 

Staff  Group  Trainer  training  began  with  a  section  table,  proceeded  to  the  CP  table  and 
then  the  C2  table.  The  team  believed  that  this  organization  would  provide  a  logical  progression 
for  staff  development.  As  discussed  previously,  they  designed  the  exercises  in  the  tables  to 
provide  a  high  likelihood  of  success  for  the  participants.  Thus,  early  exercises  and  tables  would 
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be  easier  than  later  exercises  and  tables.  During  the  trials,  the  development  team  observed  a 
significant  gap  between  performance  requirements  for  staff  section  table  modules  and  the  CP 
modules. 

From  their  observations  during  the  trials,  the  team  determined  that  staff  section  exercises 
had  not  prepared  the  sections  to  continue  to  the  CP  table.  This  meant  that  either  the  objectives  of 
the  staff  section  table  were  not  achieved  or  that  there  was  not  a  smooth  progression  between  the 
last  staff  section  exercise  and  the  first  CP  exercise.  Feedback  from  users  and  the  development 
team  indicated  that  the  staff  section  table  exercises  needed  to  be  more  challenging.  These 
exercises  as  implemented  were  too  easy  even  for  a  staff  section  at  the  crawl  level  of  training. 

From  the  trials,  the  development  team  determined  that  they  had  not  provided  a  smooth 
progression  from  the  section  table  to  the  CP  table.  The  team  looked  at  making  the  staff  section 
exercises  more  challenging 

Since  this  training  focused  on  a  staff  in  its  early  stages  of  training,  process-related  goals 
were  appropriate  especially  in  the  early  exercises.  Upon  review,  the  development  team  conceded 
that  the  training  program  did  not  adequately  assist  the  staff  section  in  achieving  the  table  training 
objectives.  The  exercises  were  too  easy  and  failed  to  focus  the  observers  adequately  on  the 
processes  needed  for  a  staff  section  to  meet  the  commander’s  informational  needs.  Correctly 
designed  these  exercises  should  focus  the  staff  section  on  what  it  must  look  for,  where  to  find  it, 
and  what  to  do  with  it  once  found. 

Whether  or  not  the  training  program  requires  a  C2  table  deserves  further  investigation. 
While  the  Staff  Group  Trainer  program  has  C2  tables,  the  developmental  complexities-increased 
number  of  workstations,  increased  number  observers,  increased  workload  on  the  interactor  cell, 
ability  of  the  system  to  handle  communication  between  CPs-associated  with  design  of  such  tables 
proved  to  be  extensive.  Because  of  these  complexities  and  additional  resources  required,  the 
usefulness  of  the  C2  exercises  on  the  Staff  Group  Trainer  system  was  questioned.  Further 
research  is  required  to  determine  if  the  training  without  the  C2  exercises  would  be  sufficient  to 
prepare  the  staff  for  Janus  or  BBS  exercises. 

The  lesson  learned  in  developing  progressive  tables  is  that  the  development  team  must 
look  carefully  at  the  objectives  at  each  level.  Because  of  the  progressive  nature  of  the  structured 
training  program,  the  staff  must  be  successful  at  the  section  level  before  continuing  to  the  next 
level.  The  training  audience  must  achieve  the  training  objectives  at  each  level  if  they  are  to  be 
successful  in  later  stages  of  the  training.  A  possible  solution  would  be  to  make  the  staff  section 
modules  more  challenging  and  have  the  section  focus  on  staff  processes;  however,  this  would  only 
partly  smooth  the  progression  between  the  section  table  and  the  CP  table.  The  development  team 
thought  the  staff  also  might  require  an  additional  level  of  exercise  before  the  CP  exercises.  This 
level  would  be  composed  of  specific  staff  group  modules.  These  modules  would  focus  on 
selected  parts  of  a  staff  that  must  work  together  in  specific  instances  (eg.,  targeting  cell 
composed  of  fire  support  and  intelligence  section  personnel).  Training  a  specific  staff  grouping 
would  better  prepare  them  to  work  together  within  the  CP  environment  of  subsequent  modules. 
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Staff  Success  in  a  Challenging  Environment 


The  training  matrix  conceptualized  at  the  beginning  of  this  project  (Figure  6)  provided  for 
multiple  entry  points  and  different  paths  through  the  program  based  upon  proficiency.  These 
entry  points  and  proficiency-based  paths  would  help  to  provide  the  flexibility  necessary  for 
“flow.”  These  were  not  developed.  While  additional  entry  points  and  paths  must  be  developed 
for  robustness  these  may  create  conditions  that  may  disrupt  the  performance  cues  designed  in  the 
base  exercise.  It  will  be  necessary  to  test  thoroughly  the  exercises  to  prevent  introducing 
confounding  factors. 

The  automated  assessment  software  should  be  designed  to  recognize  less  than  optimum 
performance  and  suggest  alternative  methods  to  provide  coaching  modes  depending  on  the 
performance  level  and  desires  of  participants.  For  example,  some  participants  may  want  coaching 
suggestions  automatically  provided,  others  may  want  suggestions  only  when  they  request  them, 
and  others  may  want  no  coaching  or  suggestions  at  all. 

Shared  Mental  Models 


As  explained  earlier,  this  shared  mental  model  concept  has  the  team  sharing  a  common 
vision  of  the  game  and  each  person’s  role  in  that  game.  Klein  and  Thordsen  (1989)  described  this 
as  a  “team  mind.”  Coaches  have  explained  this  as  teammates  having  played  together  enough  so 
that  they  anticipate  each  other’s  moves.  The  development  team  saw  the  application  of  this 
concept  as  a  staff  support  process  model  (see  Figure  10)  which  graphically  depicted  the  staff 
actions  surrounding  each  exercise’s  key  events. 

The  training  design  reinforced  this  concept.  It  provided  time  for  the  commander  to  share 
his  model  (vision)  of  the  upcoming  exercise  and  his  expectations  for  the  staff  before  each  exercise. 
The  commander  used  the  DST  to  focus  the  staff  on  what  he  anticipated  would  be  the  staffs  — -*• 

actions/interactions  during  the  exercise.  At  the  beginning  of  the  module  AAR,  the  commander 
repeated  his  expectations  and  provided  the  staff  information  on  what  he  received.  Finally,  the 
staff  and  commander  determined  the  actions  they  needed  to  improve  during  the  next  exercise  to 
ensure  the  commander  had  the  information  needed  to  conduct  the  battle. 

The  team  saw  great  potential  in  the  strategies  they  used  to  integrate  the  shared  mental 
model  concept  in  strengthening  staff  team  work.  The  approaches  may  be  useful  to  other 
developers  of  team  training  programs.  However,  the  methods  used  still  needed  to  be  refined. 
Additionally,  there  are  many  additional  training  ideas  that  could  be  implemented  that  would 
further  enhance  this  training.  Several  ideas  for  enhancing  mental  models  in  teams  are  presented  in 
Stout,  Cannon-Bowers,  and  Salas  (1996/1997)  and  Cannon-Bowers,  Tannenbaum,  Salas,  and 
Volpe  (1995). 

The  effectiveness  of  the  shared  mental  model  depends  on  the  commander.  The  team 
observed  two  different  types  of  commanders.  One  commander  provided  little  feedback  or 
direction  to  the  staff,  while  the  other  commander  was  active  and  provided  the  staff  specific 
feedback  and  direction  on  what  he  wanted.  The  difference  in  the  learning  environment  created  for 
the  staff  was  apparent.  The  team  learned  that  staff  efficiency  can  only  be  optimized  if  the  staff  is 
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made  aware  of  the  commander’s  information  requirements.  Commanders  must  become  involved 
if  staffs  are  to  maximize  performance. 

Development 

Lessons  learned  regarding  development  are  divided  into  three  groups:  exercise 
development,  training  system  (software)  development,  and  TSP  development.  There  was  an 
additional  lesson  learned  that  overlapped  two  of  these  groups-simultaneous  exercise  and 
software  development.  This  lesson  is  discussed  at  the  end  of  the  development  section. 

Exercise  Development 


Message  Traffic  Development 

Being  totally  computer  driven,  these  TSPs  provided  an  opportunity  for  the  development 
team  to  structure  exercises  more  tightly  than  any  previous  structured  training  program.  The 
message  traffic  had  to  replicate  all  of  the  information  coming  into  the  staff  yet  not  overwhelm  the 
staff  with  messages.  Developers  learned  that  it  is  extremely  time  consuming  to  develop  and 
thoroughly  test  the  message  database  for  structured  computer-driven  exercises. 

Subject  Matter  Experts 

During  this  project,  the  team  discovered  that  there  was  a  higher  specificity  of  knowledge 
required  than  in  previous  projects.  In  earlier  projects,  the  team  was  not  required  to  develop  the 
specific  message  traffic.  These  teams  only  had  to  develop  the  general  flow  of  the  battle.  In  the 
Staff  Group  Trainer  exercises,  the  development  team  had  to  create  highly  detailed  messages 
coming  into  the  staff  from  every  echelon  and  every  supporting  unit.  To  obtain  this  high  level  of 
detail,  individuals  involved  in  creating  the  messages  had  to  be  highly  competent.  As  this  type  of 
structured  staff  training  matures,  the  message  traffic  will  need  to  be  refined  for  the  staff  to  receive 
correct,  timely,  detailed  messages  over  the  correct  device.  This  type  of  detail  can  only  be 
provided  by  individuals  with  current  and  specific  knowledge  of  all  aspects  of  the  BOS.  Future 
computer-driven  exercises  need  to  allocate  ample  funds  to  ensure  that  the  technical  subject  matter 
expertise  is  made  available. 


Training  System  Development 

All  developers  need  a  clear  picture  of  the  desired  training  environment.  However,  it  is 
especially  critical  for  software  developers.  If  possible,  they  should  also  be  provided  information 
on  potential  expansions  of  the  system.  This  information  helps  them  design  flexible,  scaleable  code 
which  will  make  future  development  efforts  less  expensive.  Given  no  direction,  coders  take  low- 
risk  coding  approaches  to  ensure  code  meets  delivery  requirements.  This  code  will  have  high 
reliability  at  an  earlier  development  stage,  but  may  lack  the  flexibility  needed  for  expansion.  To 
facilitate  this,  managers  supervising  this  code  development  should  be  aware  of  potentials  in  the 
field  (e.g.,  GUI  features,  such  as  “enable”  and  “disable”  button  selections;  and  options  in  system 
design,  such  as  client  server  versus  peer-to-peer  design). 
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User-Friendiv  Interfaces 


Although  the  system  was  drastically  improved,  it  still  needs  an  improved  GUI  to  reach  the 
ease  of  operation  required  for  a  fielded  system.  At  the  beginning  of  this  project,  the  legacy  system 
interfaces  were  difficult  and  time  consuming  for  the  developer  team  to  use.  The  data  input  system 
developed  in  this  project  greatly  simplified  the  developer  input  requirements.  This  was  important 
because  it  allowed  more  exercise  variations  to  be  tested.  The  lesson  learned  is  that  developer 
tools  must  be  considered  in  software  development,  not  just  software  for  end  users. 

Emulate  Fielded  Systems 

The  brigade  commanders  interviewed  do  not  want  valuable  staff  training  time  spent 
learning  a  computer  system  that  only  drives  the  exercise.  They  want  staff  members  to  practice  on 
their  own  Army  Tactical  Command  and  Control  System  (ATCCS)  systems;  for  example,  the  S3 
section  wanted  to  use  their  Maneuver  Control  System.  To  do  this  the  ultimate  training  system 
could  be  embedded  in  the  various  ATCCS  systems,  emulate  the  user-interface  characteristics  of 
the  actual  tactical  equipment,  or  be  very  easy  to  learn  (less  than  one  hour  for  proficiency). 

If  ATCCS  equipment  was  emulated  both  operators  and  staff  could  be  trained.  The  staff 
would  focus  on  training  the  staff  section  in  how  best  to  use  the  system’s  capabilities. 

Training  Support  Package  Development 

As  discussed  previously,  the  TSP  includes  both  the  paper-based  instructions  and  more 
non-traditional  items  such  as  the  system  software,  multimedia  presentations  (previews,  and 
AARs),  and  the  message  database.  The  TSP  also  contains  a  “how  to”  conduct  the  training  (train- 
the-trainer)  program.  The  following  sections  discuss  some  of  the  lessons  learned  about  both  the 
paper-based  portions  and  the  non-traditional  components.  -  -  ■  - 

Training  Support  Package  Organization 

During  previous  VTP  structured  training  projects  (SIMUTA,  SIMUTA-B,  and 
SIMBART),  the  development  teams  tried  various  ways  to  organize  the  paper-based  TSPs  to 
make  them  easier  for  a  training  team  to  use  (R.  G.  Hoffman  et  al.  1995;  Graves  &  Myers,  1997; 
Koger  et  al.  1996).  In  these  projects,  the  training  teams  prepared  execution  preview  materials, 
job  aids,  checklists,  and  starting  and  ending  exercise  materials.  This  project  organized  the  paper- 
based  TSPs  into  the  five-volume  sets  described  earlier.  The  O/C  team  felt  this  configuration  was 
difficult  to  use.  It  required  them  to  extract  and  copy  TSP  materials  to  make  team  member 
workbooks.  Based  on  feedback  from  the  O/Cs,  the  developers  created  workbooks  that  were 
approximately  ten  pages  per  exercise.  These  workbooks  provided  the  O/Cs  the  material  they 
needed  and  were  evaluated  as  “user  friendly.” 

The  development  team  has  learned  that  to  be  useful  to  the  training  team,  the  mandatory 
information— execution  procedures  and  design  philosophy— must  be  presented  in  a  quickly 
digestible,  user-friendly  format.  The  paper-based  TSP  may  not  be  the  best  means  to  provide 
materials.  Potential  ways  to  replace  traditional  paper  may  be  formats  such  as  videotape  or 
computer-assisted  instruction.  Perhaps  preview  and  AAR  materials  could  be  embedded  on  the 
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training  system  and  some  form  of  electronic  clipboard  or  hand-held  computer  may  offer  relief 
from  paper  training  packages  for  the  training  team.  Various  options  need  to  be  explored  to 
provide  job-aids  and  checklists  to  the  training  team.  Future  efforts  should  consider  non-paper- 
based  TSPs. 

Structured  Information  Presentation 

Structuring  took  place  on  several  levels  to  include  structured  writing,  message  previews, 
and  AARs.  The  following  sections  discuss  the  lessons  learned  in  structuring  at  these  levels. 

Structured  writing.  Structured  writing  has  been  shown  to  be  beneficial  in  previous  VTP 
projects  (Koger  et  al.  1996;  Graves  &  Myers,  1997).  In  this  project,  the  training  team  found  that 
structured  writing  helped  them  understand  the  written  material  in  the  TSPs  more  quickly.  In  the 
prototype  exercise  reviews,  the  participants  requested  that  even  more  use  be  made  of  some  of  the 
structured  writing  presentation  techniques.  Specifically,  the  participants  wanted  information  in  a 
short,  to-the-point  presentation.  The  short  “bullets”  rather  than  prose  decreased  the  amount  of 
time  required  to  digest  the  materials.  The  team  maximized  structured  writing  principles  (Horn, 
1995)  in  the  TSPs.  In  the  future,  paper-based  TSPs  should  use  structured  writing. 

Message  formats.  The  original  SIMUTA  C/ST  messages  did  not  use  standardized 
formats.  The  development  team  converted  all  messages  to  the  formats  in  Field  Manual  71-3 
(Department  of  the  Army,  1988a).  The  staff  read  messages  in  these  formats  and  also  used  them 
to  compose  their  own  messages.  Familiarity  with  the  formats  permitted  participants  to  more 
rapidly  parse  information.  Future  projects  should  implement  ATCCS  formats  where  possible. 

Previews.  Multimedia  previews  were  not  part  of  the  design.  They  were  developed  and 
implemented  for  some  modules  and  exercises  to  examine  their  potential.  The  general  situation 
multimedia  previews  were  enthusiastically  received  by  the  staff  and  training  team.  Multimedia 
previews  must  continue  to  be  developed  if  such  training  programs  are  to  be  exportable. 

The  development  team  discovered  that  high-quality  previews  are  costly  to  develop.  A 
dedicated,  knowledgeable  graphic  artist  with  sophisticated  software  and  hardware  is  necessary  to 
keep  costs  at  a  reasonable  level.  While  development  team  members  became  more  proficient  in 
scripting  and  composing  the  previews,  thus  decreasing  the  cost  per  preview,  full  implementation 
of  dynamic/interactive  links  to  training  performance  measures  will  increase  costs. 

Staff  section-specific  multimedia  previews  were  not  developed.  Brown  (1992)  has 
suggested  that  while  the  staff  section-specific  previews  are  probably  the  most  difficult  to  deliver, 
they  offer  the  most  training  benefit.  Part  of  this  premise  was  qualitatively  evaluated  during  this 
project.  The  development  team  provided  detailed  preview  exercise  materials  to  the  training  team 
for  most  of  the  exercises.  When  the  material  was  used  staff  performance  was  positively  impacted. 
Additional  work  is  required  to  develop  detailed  material  for  each  staff  section  for  each  exercise. 
After  the  material  is  developed  and  tested  for  effectiveness,  resources  should  be  devoted  to 
prepare  multimedia  material  for  all  staff  sections.  The  development  team  has  learned  that 
maximum  structuring  of  materials  is  necessary  to  ensure  consistent,  repeatable  training. 
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After  Action  Reviews.  The  automated  delivery  of  scripted  message  traffic  in  the  Staff 
Group  Trainer  Project  provided  more  structure  to  the  training  program  than  in  previous 
programs.  The  impact  of  this  structure  was  most  evident  in  the  AAR.  The  structured  message 
traffic  and  events  for  an  exercise  provided  the  framework  necessary  to  focus  the  AAR  on  specific 
training  objectives  that  were  cued  by  message  traffic.  The  team  designed  a  structured,  multimedia 
AAR  that  kept  the  training  team  more  closely  aligned  with  the  design  and  made  AARs  easier  for 
the  O/Cs  to  conduct.  Since  future  computer-driven  staff  training  programs  need  to  be  designed  as 
exportable,  easy-to-use  packages,  the  structured,  multimedia  AAR  will  help  a  less  experienced 
training  team  better  achieve  the  training  objectives.  The  computer-driven  AAR  also  needs  to  be 
extended  to  the  staff  section  level. 

Observer  Checklists.  Observer  materials  must  be  explicit  and  not  require  extensive 
familiarity  with  the  scenario.  Instead  of  vague  guidance,  staff  actions  should  specify  behaviors  for 
observers  to  look  for. 

Train-the-Trainer  Requirements 

The  train-the-trainer  program  as  designed  required  approximately  three  days.  It  was  to  be 
presented  by  an  individual  very  knowledgeable  of  the  program  and  its  underlying  concepts.  After 
the  brigade  commander  interviews,  it  became  obvious  that  any  exportable,  useable  train-the- 
trainer  program  must  be  significantly  shorter  and  easier  to  implement  in  the  field.  The  lesson 
learned  is  for  the  training  developer  to  ensure  that  the  train-the-trainer  program  is  also  designed 
and  developed  to  meet  the  needs  of  the  audience. 

Simultaneous  Exercise  and  Training  System  Development 

Simultaneous  training  and  software  development  led  to  scheduling  difficulties.  Software 
deliveries  were  not  well  aligned  with  the  training  development  schedule.  Training  developers 
were  not  able  to  test  the  training  exercises  on  the  system  until  the  pilots.  If  simultaneous  training 
and  software  development  is  planned,  schedules  must  be  aligned  to  allow  adequate  internal  testing 
prior  to  external  testing.  This  may  require  more  flexibility  in  test  schedules  or  additional  time 
allotted  to  compensate  for  unexpected  problems. 

The  software  lot  development  must  be  integrated  in  the  program  development  of  the  non¬ 
computer  components.  This  requires  delivery  of  capabilities  based  on  an  analysis  of  how  the  code 
must  be  developed.  For  example,  item  1  on  the  user's  priority  list  might  require  that  items  15  and 
16  would  need  to  be  developed  first.  The  coding  requirements  must  be  linked  with  the 
capabilities  required  to  test  the  system  during  development. 

Demonstrations 

During  the  brigade  pilot,  there  was  a  sensing  that  the  training  team  had  not  been  provided 
with  a  clear  concept  of  the  TSPs.  At  the  start  of  the  last  day  of  the  brigade  pilot,  the  development 
team  played  the  role  of  a  brigade  staff  and  executed  one  of  the  C2  exercises.  This  demonstration 
allowed  the  training  team  to  see  how  a  staff  was  expected  to  execute  the  exercise  on  the  training 
system.  This  demonstration  appeared  to  clear  up  a  number  of  questions  the  training  team  had 
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about  how  the  training  should  be  executed.  Based  on  this  response,  the  development  team 
concluded  that  a  demonstration  would  help  both  the  training  teams  and  the  staffs  understand  how 
the  training  program  was  executed.  The  development  team  added  a  live  demonstration  to  the 
start  of  the  Train-the-Trainer  Program  and  the  staff  orientation. 

This  demonstration  was  labor  intensive.  It  required  the  training  team  to  role-play  as  an 
entire  staff.  There  are  more  efficient/effective  ways  to  conduct  this  demonstration,  e.g., 
videotape.  A  videotape  could  be  used  to  highlight  specifics  of  the  training  program.  More  work 
is  required  to  develop  the  demonstration  for  this  training  program.  When  it  is  fully  developed  it 
should  be  placed  on  suitable  media. 


Implementation 

There  were  two  lessons  learned  in  implementing  this  program,  relating  to  the  role  and 
structure  of  the  training  team  and  the  physical  environment  for  the  training. 

Training  Team 

This  project  and  previous  VTP  programs  (R.  G.  Hoffman  et  al.  1995;  Koger  et  al.  1996; 
Graves  &  Myers,  1997)  have  faced  problems  with  acceptance  of  the  training  program  design. 

This  report  discussed  means  of  providing  the  training  team  with  information  and  rationales  for  the 
training  program  using  TSPs  and  the  Train-the-Trainer  Program.  Cognizance  of  the  design  does 
not  ensure  acceptance.  The  training  team  must  be  convinced  that  the  training  program  is  effective 
given  the  time  and  fiscal  restraints  of  tactical  units.  Achieving  acceptance  is  difficult  when  the 
approaches  are  different  than  what  they  are  convinced  works. 

Since  this  and  the  previous  VTP  programs  were  research  projects,  at  least  part  of  the 
explanation  should  include  the  fact  that  this  is  research  and  that  the  training  design  needs  to  be 
followed  to  determine  its  effectiveness.  Only  by  being  tested  can  the  design  be  fully  evaluated. 
The  development  team  must  take  the  time  and  effort  to  ensure: 

•  The  training  team  leadership  understands  that  this  is  a  research  project. 

•  In  research  projects  some  concepts  are  tested  that  do  not  work. 

•  In  research  projects  the  training  team  members  must  implement  the  training  program’s 
design  to  the  best  of  their  abilities  so  that  the  design  can  be  evaluated. 

The  development  team  must  involve  the  training  team  and  participant  staff  leadership  early 
in  the  program. 


Physical  Features 

The  participants  commented  that  the  staff  sections  should  be  laid  out  the  same  as  in  a  CP. 
That  means  that  the  physical  relationship  between  sections  should  be  consistent  with  the  actual 
unit  operating  environment.  When  it  is  not  cost  prohibitive,  face  validity  should  be  implemented. 
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The  participants  also  wanted  the  tasks  performed  similarly  to  the  way  they  would  be 
performed  using  their  regular  equipment.  The  most  commonly  made  comment  concerned  posting 
the  map.  In  the  pilots  and  trials,  there  were  no  paper  maps  and  associated  overlays  available  to 
the  staff.  All  of  the  work  with  maps  was  required  to  be  done  on  the  workstations.  The 
participants  wanted  the  ability  to  post  maps  in  the  same  manner  as  in  the  field  CP  to  allow  transfer 
of  training.  In  future  training  programs,  the  task  of  posting  a  map  could  be  performed  on  either 
paper  maps  or  on  system  maps,  at  the  option  of  the  participants  (see  equipment  emulation 
discussed  earlier).  Paper  maps,  interestingly,  were  not  of  concern  to  the  brigade  commanders 
interviewed. 


Evaluation 

Several  major  lessons  were  learned  in  the  evaluation  phase.  First,  the  formative  evaluation 
model  used  in  this  program  is  a  valid  model.  However,  adjustments  can  be  made  in  execution  to 
improve  results.  Second,  participants~as  per  the  design  plan-are  key  to  a  valid  evaluation  of  a 
research  training  project. 


Formative  Evaluation  Methods 

During  the  project,  the  development  team  did  not  conduct  the  formative  evaluation  as  they 
had  planned.  Certain  portions  were  delayed  or  moved  into  later  phases  of  development.  As 
Tessmer  (1993)  pointed  out,  the  resistance  to  revision  increases  as  the  project  gets  closer  to 
completion.  M.  Hoffman  (1986)  indicated  that  every  project  has  a  pre-emption  point.  According 
to  Hoffman,  a  pre-emption  point  is  a  point  where  changes  can  no  longer  occur  because  financial 
or  emotional  investment  is  too  great  to  make  the  change.  Since  portions  of  the  evaluation  were 
moved  closer  to  the  project  completion,  the  implementation  of  changes  became  increasing  more 
difficult  to  make  and  still  meet  the  contract  delivery  schedule.  In  effect,  some  of  the  evaluations 
were  conducted  either  very  near  or  beyond  the  pre-emption  point. 

The  lesson  learned  is  that  each  phase  of  a  formative  evaluation  is  important.  Phases  of 
evaluation  should  be  conducted  and  revision  recommendations  provided  early  enough  in  the 
development  cycle  so  that  they  can  be  used.  Certain  aspects  of  the  formative  evaluation,  such  as 
an  expert  review  or  one-to-one  evaluation,  should  be  done  as  early  as  possible  in  a  project. 

Ample  time  needs  to  be  scheduled  into  the  development  cycle  to  allow  for  revisions  based  on  the 
formative  evaluation.  Without  ample  time  for  revisions,  the  evaluation’s  usefulness  for  that 
project  may  not  be  realized.  Future  projects,  however,  may  be  able  to  benefit  from  the 
evaluation. 


Participants 

Although  many  of  the  participants  did  an  outstanding  job  of  playing  their  roles,  the  staffs 
for  the  trials  were  not  an  actual  battalion  or  brigade  staff  These  individuals  assembled  to  form  a 
surrogate  staff  only  for  the  trial.  They  were  usually  the  appropriate  rank  and  branch  or  specialty. 
However,  since  this  training  program  design  was  focused  on  training  a  staff  to  respond  to  the 
information  needs  of  the  commander,  the  ad  hoc  staff  had  serious  short  falls.  These  participants 
lacked  the  synergy  and  motivation  of  a  regular  staff  working  with  their  commander  in  a  training 
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environment.  The  lesson  learned  in  this  project  is  that  the  target  audience  should  be  used  in  all 
trials. 


CONCLUSIONS 
Staff  Group  Trainer  Project 

The  Staff  Group  Trainer  Project  developed  TSPs  bridging  the  gap  between  individual  and 
integrated  staff  training.  The  training  focused  on  preparing  the  staff  to  meet  the  commander's 
information  needs.  The  progressive  exercises  trained  the  staff  in  their  procedures  and  prepared 
them  for  their  next  level  of  training.  The  decision-making  exercises  led  a  staff  through  the 
complete  staff  support  cycle. 

Field  commanders  continue  to  express  a  need  for  battalion  and  brigade  structured  staff 
training.  The  Staff  Group  Trainer  Project  established  a  solid  base  for  future  design,  refinement, 
and  implementation.  With  downsizing,  decreased  opportunities  for  field  training,  and  rapid  staff 
turnover,  the  Staff  Group  Trainer  technology  provides  a  high-payoff  training  option. 

The  overhead  for  staff  training  cannot  be  labor  intensive  and  should  be  largely  invisible  to 
the  staff  being  trained.  Today,  staff  personnel  cannot  afford  to  invest  substantial  time  in  learning 
how  to  use  a  training  system.  The  support  system  must  either  emulate  or  run  on  actual 
equipment,  or  require  a  short  training  time.  Further  development  of  the  Staff  Group  Trainer 
technology  should  explore  these  requirements. 

A  follow-on  to  the  Staff  Group  Trainer  Project  to  design  and  develop  a  program  that  can 
be  implemented  without  a  significant  support  staff  should  be  considered.  Commanders  indicated 
that  obtaining  a  large  support  staff  or  traveling  to  a  training  site  for  this  type  of  training  is  not 
feasible.  Any  staff  training  program  must  be  easy  for  the  commander  to  use  within  his  assets  or 
with  minimal  augmentation  and  available  at  the  commander's  home  station.  Future  developments 
of  structured,  computer-driven  staff  training  systems  must  take  into  consideration  field  training 
needs  and  start  with  a  front-end  analysis.  Program  designs  must  then  be  generated  in  light  of 
these  needs. 
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Training  Program  Potential 


The  Army  has  a  need  for  training  tools  to  enable  staff  groups  to  become  proficient  at 
critical  functions.  Unit  commanders  want  a  program  to  train  staff  fundamentals  prior  to 
conducting  more  elaborate  and  costly  training  exercises.  Such  a  program  must: 

•  be  turnkey, 

•  have  low  overhead  requirements  (training  personnel), 

•  be  easy  to  use,  and  involve  short  train-up  requirements  (administrators  and  trainees), 

•  consist  of  short,  intense  vignettes,  and 

•  contain  modules  that  take  no  more  than  half  a  day  to  complete. 

A  training  team  in  which  the  commander  is  the  senior  trainer,  even  though  team  members 
may  not  be  permanently  assigned,  remains  a  key  component  of  a  staff  training  program.  The 
training  program  is  his  tool  to  train  his  staff.  The  training  team  must  work  for  him  and  support  his 
informational  or  situational  requirements.  To  optimize  training,  the  training  team  must  have 
available  a  train-the-trainer  program  and  TSPs  which  are  concise,  efficient,  and  easy  to  use. 

Recommendations  for  Further  Research 

The  following  list  is  based  on  this  project’s  lessons  learned  and  summarizes  areas  for 
further  research  and  development  to  meet  unit  commander's  needs. 

1 .  Further  work  is  desirable  to  merge  the  BFs  into  new  and  existing  structured  training 
programs.  Since  the  BF  and  the  Staff  Group  Trainer  Project  were  conducted  concurrently 
many  of  the  products  developed  in  the  BF  project  were  not  totally  integrated  into  the  training 
programs. 

2.  The  training  team  availability  for  structured,  computer-driven  staff  training  programs  will 
remain  a  problem  within  the  Army.  Further  research  should  be  conducted  to  determine 
minimum  staffing  requirements  and  trade-offs  associated  with  various  training  team 
configurations. 

3.  Further  work  is  needed  to  enhance  the  configuration  and  presentation  of  TSPs.  Possibilities 
include: 

•  Putting  the  TSP  in  an  electronic  medium. 

•  Presenting  some  of  the  material  in  the  TSP  via  multimedia  techniques. 

•  Using  an  electronic  clipboard-type  device  for  observer  checklists. 
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4.  Further  improvements  can  be  made  to  the  train-the-trainer  program.  The  program  needs  to  be 
exportable,  concise,  and  easy  to  use.  Some  form  of  multimedia  or  computer- 
assisted/managed  training  may  be  suitable.  This  program  must  be  tied  to  the  training  team 
availability,  number  of  trainers  required,  and  the  time  constraints  these  individuals  are  under. 

5.  Further  investigation  into  the  utility  and  means  of  providing  the  staff  pre-exercise  materials  is 
required.  This  project  used  multimedia  for  the  general  preview  with  very  positive  results. 
Effective  means  of  presenting  staff  section-specific  previews  still  need  to  be  determined. 

6.  Investigation  on  whether  the  C2  exercises  are  required  to  prepare  a  staff  for  Janus  or  BBS 
should  be  conducted. 

The  Staff  Group  Trainer  Project  advanced  the  development  process  of  providing  battalion 
and  brigade  staff  training  programs  to  the  commander  as  a  tool  to  train  his  staff.  More  work  is 
required  to  refine  these  programs  and  the  delivery  system  into  a  useable  tool  for  the  commander 
in  the  field.  This  project  provided  direction  for  future  developments  in  this  area. 
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ACRONYMS  and  ABBREVIATIONS 


AAR 

After  action  review 

AFRU 

Armored  Forces  Research  Unit 

ARI 

U.S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences 

ATCCS 

Army  Tactical  Command  and  Control  System 

BBS 

Brigade/Battalion  Battle  Simulation 

BC 

Battle  Captain 

BF 

Battlefield  Function  (formerly  Critical  Combat  Function  -  CCF) 

BOS 

Battlefield  Operating  System 

BSTS 

Battle  Staff  Training  System 

C/ST 

Commander/staff  trainer  (currently  called  Staff  Group  Trainer) 

C2 

Command  and  Control 

CATK 

Counterattack 

CCF 

Critical  Combat  Function 

COBRAS 

Combined-arms  Operations  at  Brigade  Level,  Realistically  achieved 
through  Simulation 

COFT 

Conduct-of-Fire  Trainer 

CP 

Command  post 

CTCP 

Combat  trains  command  post 

CVCC 

Combat  Vehicle  Command  and  Control 

DST 

Decision  Support  Template 

ENDEX 

End  of  exercise 

FC 

Field  Circular 

FRAGO 

Fragmentary  order 

FSB 

Forward  Support  Battalion 

FSO 

Fire  Support  Officer 

FXXITP 

Force  XXI  Training  Program 

GUI 

Graphic  User  Interface 

ITTBBST 

Innovative  Tools  and  Techniques  for  Brigade  and  Below  Staff  Training 

LAN 

Local  Area  Net 

NCO 

Non-Commissioned  Officer 

O/C 

Observer/controller 

O/C/I 

Observer/controller/interactor 

OIC 

Officer  in  Charge 

OPORD 

Operation  Order 

PSNCO 

Personnel  StaffNon-Commissioned  Officer 

R&D 

Research  and  Development 

RCVTP 

Reserve  Component  Virtual  Training  Program 

SI 

Personnel  Officer 

S2 

Intelligence  Officer 

S3 

Operations  Officer 

S4 

Logistics  Officer 

SGT 

Staff  Group  Trainer 
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SIMBART 

Simulation-based  Mounted  Brigade  Training 

SIMNET 

Simulation  Networking 

SIMUTA 

Simulation-based  Multiechelon  Training  Program  for  Armor  Units 

SIMUTA-B 

Simulation-based  Multiechelon  Training  Program  for  Armor  Units 
Battalion  Exercise  Expansion 

SOW 

Statement  of  work 

TACCP 

Tactical  Command  Post 

THP 

Take-home  package 

TOC 

Tactical  operations  center 

TRADOC 

U.S.  Army  Training  and  Doctrine  Command 

TSOP 

Tactical  standing  operating  procedures 

TSP 

Training  Support  Packages 

VTP 

Virtual  Training  Program 

XO 

Executive  Officer 
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